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Chapter  1 


1 . 1  I nt  roduct i o  n 

There  are  several  reasons  that  the  lambda  calculus  is  impor¬ 
tant  for  designers  and  implementors  of  programming  languages. 
One  of  the  first  uses  of  the  lambda  calculus  as  a  tool  of  pro¬ 
gramming  linguistics  occurred  in  the  mid  1960s  when  Strachey  and 
Landin  used  it  to  elucidate  the  semantics  of  Algol-60.  The 
lambda  calculus  was  picked  because,  as  we  shall  see,  it  has  the 
same  scope  rules  as  block  structured  languages.  This  allowed 
the  consequences  of  these  rules  to  be  studied  in  a  distill ed  and 
simple  context.  In  particular,  this  allowed  the  implementation 
of  block  structured  languages  to  be  investigated  without  the  com- 
plexities  of  “real"  languages.  In  this  manual  you  will  see  both 
interpreted  and  compiled  implementations  of  the  lambda  calculus  - 
seminal  techniques  that  can  be  used  or  adapted  for  many  other 
languages.  For  instance,  the  cl osure  implementation  concept  is 
important  in  understanding  coroutines,  processes  and  the  “lazy 
evaluation"  techniques  discussed  in  Part  II. 

The  symmetry  and  simplicity  of  the  lambda  calculus  sets  a 
standard  against  which  all  languages  can  be  compared.  For 
instance,  the  essential  equivalence  between  formal  parameters  and 
declarations  in  the  lambda  calculus  suggests  a  solution  to  many 
problems  of  language  design.  This  has  been  used  in  several 
experimental  languages,  e.g.  Quest. 

Although  the  lambda  calculus  is  capable  of  computing  any 
computable  function,  it  provides  a  model  of  computation  that  is 
much  closer  to  real  languages  than  most  other  such  models  (e.g. 
Markov  algorithms,  Turing  machines,  recursive  functions).  It  is 
therefore  more  relevent  to  the  real  problems  of  language  design. 

The  programming  practices  and  modes  of  thought  used  with  the 
lambda  calculus  and  its  derivatives  (such  as  LISP)  have  formed 
the  foundation  of  funct i onal  programmi ng  -  the  method  of  program¬ 
ming  recently  popul ari zed  by  Backus  and  cha r ac t er i zed  by  a  high- 
level  applicative  programming  style.  The  lambda  calculus  is 
essential  for  an  understanding  of  the  design  and  implementation 
of  such  languages. 


Chapter  2 


I . 7  The  Lambda  Calculus 
1.2.1  calculus  defined. 


'»'e  will  be  using  the  lambda  calculus  as  a  model  of  computa¬ 
tion.  That  is,  we  will  be  usinq  the  lambda  calculus  as  a  wav  or 
describing  the  meaning  or  programs  and  as  a  guide  to  the  imple¬ 
mentation  or  programming  lancuaqes.  A  ca Iculus  is  a  notation 
which  can  be  manipulated  mechanically  to  achieve  some  end.  "Cal¬ 
culus"  is  the  Latin  word  tor  "pebble"  and  is  derived  from  the 
fact  that  people  used  to  do  arithmetic  by  manipulating  pebbles. 
("Calc"  is  the  Latin  word  for  "limestone"  and  is  also  the  basis 
tor  words  such  as  "calculate".)  You  are  probably  familiar  with 
the  differential  and  integral  calculi.  In  these  it  is  possible 
to  manipulate  formulas  accordina  to  the  rules  of  integration  and 
di tf erentiation  to  get  results  that  would  otherwise  have  to  be 
derived  by  solving  complicated  limits.  You  may  also  be  familiar 
with  the  propositional  and  Predicate  calculi.  In  these  certain 
forms  of  deductive  reasoning  can  be  performed  by  the  mechanical 
manipulation  of  symbols. 

The  reason  for  developing  a  calculus  is  that  by  reducing 
some  Process  to  a  set  of  simple  mechanical  rules  one  decreases 
the  chances  of  making  an  error.  Of  course,  the  fact  that  the 
rules  of  a  calculus  are  mechanical  and  strictly  defined  makes 
them  ideal  for  manipulation  bv  computer.  The  lambda  calculus  is 
a  calculus  which  models  (mimics)  the  process  of  computation 
itself.  Under  the  now  oenerally  accented  definition  of  computa¬ 
bility,  it  has  been  shown  (by  Alonzo  Church,  the  inventor  of  the 
lambda  calculus,  and  Alan  Turing)  that  anything  that  can  be  done 
on  any  computer  can  also  be  done  in  the  lambda  calculus  (althouqh 
perhaps  very  inefficiently). 

1.7.2  bound  variables  defined . 

One  of  the  central  ideas  of  the  lambda  calculus  is  that  or  a 
bound  variable  (sometimes  called  a  dummy  variable) .  ^ound  vari¬ 
ables  are  common  in  all  mathematical  notations,  for  instance,  in 
the  summation 


0. 

i  =  1 


o  t 


the 


•  ;  • 


is  the  bound  variable. 


It  is  a  characteristic 


bound 


For  i nstance , 
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variables  that  it  doesn't  natter  what  thev  are. 


I  * 

k  =  i 


neans  exactlv  the  same  t^inq  as  the  orevious  summation, 
larlv.  the  inteqral  of  x'-lx  with  resoect  to  x: 

fx^-3x  dx 
T) 

is  the  same  as  the  integral  ot  u^-3u  with  resoect  to  u: 

*fu^-3u  du 

In  set  theory,  the  set  of  all  x  such  that  x>0  is  the  same  as 
set  of  all  n  such  that  n>0: 

{x!x>0}  =  {n!n>0} 


Mso,  a  proposition  such  as  "for  every  x,  x+l>x": 

*x{  X+i>X  } 


is  the  same  as  the  proposition  "for  every  v,  v+l>y”: 

Vyf  y+i>v  } 


*3  i  m  i  - 


the 


In  the  following  examoles  the  hound  variables  are 
right. 


listed  on  the 


xor ess  ion 


iounr! 
va  r  i  able 


Vernalization 


the  sum  tor 


d  !  x  --  3x  ) /d  x 


the  oroduct  tor  i  from 


the  derivative  with  resDect 


the  derivative  with  resoect  to  v  ot 


the  intecrrai 


the  set  ot  all  x  such  that 


there  exists  a  y  such  thac 


any  x  such  that 


the  unioue  y  such  that 


T.7.3  bound  and  tree  occurrences .  and  scone . 

Two  ideas  that  will  be  verv  useful  to  us  are  bound 
occurrence  and  t'  ree  occurrence .  Consider  the  exoression 

i  ±  A  i  ^ 

1  =  1  1 

The  occurrence  ot  'j'  in  1  is  called  a  Hound  occurrence  or 

the  variable  ’j’.  It  is  bound  by  the  summation  ooerator  11}. 

which  is  called  the  hi nd ing  site  (or  just  binding )  of  this 
occurrence  of  '1'.  we  can  see  that  'j'  is  bound  by  noting  that 

we  can  change  it  to  any  other  variable  (exceot  * i * )  without 

changing  the  meaning  of  the  expression.  '’or  instance, 


1 


Any  occurrence  of  a  variable  that  is  not  a  bound  occurrence  is 
called  a  tree  occurrence.  Tor  instance,  ’ i 1 ,  ’n'  and  ’A’  all 
occur  tree  in  tue  above  expression.  Clearly,  it  we  change  a  tree 
variable  we  have  changed  the  meaning  of  the  expression: 
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votice  that  when  we  say  that  an  occurrence  of  a  variable  is  bound 
or  tree,  we  say  this  relative  to  some  expression.  por  instance, 
' i '  is  tree  in 


Kut  is  bound  in 


n 


>.  and 

j  =  i 


Similarly,  * i ’  is  free  in  the  above  expressions,  but  bound  in 


a 

i  =  i 


(i  ! 


.£.*ij> 

1  =  i  1 J 


The  bindina  site  of  a  variable  determines  its  scope ,  which  is  the 
region  of  the  expression  over  which  that  variable  is  bound.  This 
region  is  usually  indicated  by  some  textual  convention,  such  as 
brackets  or  parentheses.  To  state  things  differently,  all 
occurrences  of  a  variable  which  are  in  the  scooe  ot  a  bindina  of 
that  variable  are  bound  occurrences  of  that  variable.  The  fol¬ 
lowing  figures  exemplify  these  concents: 


scooe  of  x 
l - 1 - 1 

x>y  } 


bindina  s  /  free  occurrence  of  v 

site  ot  x  bound  occurrence  ot  x 


binding  . 
site  of  x 


scope  ot 


tree  occurrence 
bound  occurrences  ot  x 


of 


y 


As  we  have  already  seen,  it  is  perfectly  meaningful  tor  scooes  to 
be  nested  within  other  scopes.  Some  examples  of  nested  scopes 
are  shown  below  (the  brackets  indicating  scope  are  called  scooing 
lines)  : 


-  10  - 


l  It 

i  =  l  I  j  =  i  A V 


scone  ot  t 

_ 1 


scone  of  1 


tx  ^v°+xv  dv  dx 
T)  T),'  , 


scone  ot  y 

_ i 

scope  or  x 

We  can  summarize  these  ideas  as  follows: 

*  h j nd i ng  site  of  a  variable  determines  its 

h  An  occurrence  of  a  variable  is  bound  it  it  is 
of  a  bindinq  site  of  that  variable. 

An  occurrence  of  a  variable  is  free  otherwise 


scope . 
in  the 


scone 


RXERCISRS: 


ror  each  variable  occurrence  in  the  tollowina  expressions, 
indicate  whether  it  is  a  bindinq  site,  a  bound  occurrence,  or  a 
free  occurence.  Rraw  sconing  lines  to  indicate  the  scone  ot  each 
bindinq. 


1. 

2. 

3. 

4. 

5. 

?  t 
3. 


{  n  I  n^m  ) 

Tx  sin (x/vl  dx 


rx^sinfyx)dy  dx 
f)  7)  1 


x2  +  y2 


i] 


Sx&yK'  xy 


a.  a. 

i  =  l 


vx (X«7  =>  3y  (yS7  A  X  = 
{ x  I  x > 0 }  U  ( x  I  x<0 1  = 


v+1  )  1 
{xlx^O} 


e 


1 


sinh (x) 


T.2.4  renaming  bound  variables. 


As  we  have  seen,  bound  variables  are  arbitrary.  This  is  one 
reason  they  are  often  called  dummy  variables;  they  only  serve  to 
establish  a  connection  between  carts  of  an  expression.  ^ound 
variables  are  the  oronouns  ot  mathematics. 

Chanqing  a  bound  variable  to  another  variable  does  not 
change  the  meaning  ot  an  expression.  For  instance, 

CL 

A .•  ^  and  -i 

i  =  i  ^  k=l 

both  mean  the  sum  of  the  j-th  column  ot  the  matrix  A.  Suppose  we 
change  the  bound  variable  to  '  j  '  : 


This  sums  the  diagonal  of  the  matrix;  we  have  altered  the  meaning 
of  the  expression!  We  got  into  this  trouble  because  we  changed 
the  bound  variable  * i '  to  the  variahle  '  j  '  ,  which  already 
occurred  within  the  expression.  '’’hus,  the  occurrence  ot  ’j'  in 
A: j  became  acc identlv  bound .  ^his  is  called  a  collision  of  vari¬ 
ables  .  The  conclusion  that  can  be  drawn  from  this  is:  we  can 
change  a  bound  variable,  throughout  its  scope,  to  another  vari¬ 
able  only  if  the  latter  variable  does  not  occur  with  in  that 
scooe. 


FXFFCISFS: 

For  each  expression  determine  whether  the  indicated  change 
of  variable  alters  the  meaning  of  the  expression. 


1. 

f x 1 x>y } ; 

change  x 

=  > 

2. 

{ x 1 x>y  } ; 

change  x 

=  0 

3  . 

me 

3-xy) ; 

change 

X 

4. 

same ; 

;  change  x  => 

V  . 

5. 

Vx C3y  (y>xl 1 ;  y  => 

X  . 

<5. 

V  +  v2 

J ;  v  => 

X  . 

7. 

sinh (x)  = 

eX.e-X 
- 2 - ' 

X 
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q.  fn>,m'>el  M  fel  sin(e)=o  i;  9  =>  m. 

9  .  {xlx>0}  U  (y|v<0>;  v  =>  x. 

10.  ^  a> ,  +  ^  ^  t  ;  i  =>  i  . 

i  =  l  1  j  =  l  ' 

a  a 

11.  5l  i  *  .  “  V-s ;  j  =  >  i  . 
i=l  ]=1  J 

1.2.5  function  definition . 

r''hen  bound  variables  are  used  in  function  definitions  tbev 
are  often  called  formal  parameters .  ^or  example,  in 

t  (x)  =  x2-3x 

1 x ’  is  the  bound  variable  or  formal  Parameter.  This  is  different 
from  the  previous  examples  of  bound  variables  in  that  the  bound 
variable  and  the  function  name  are  tied  toaether.  The  lambda 
calculus  provides  a  notation  for  functions  which  does  not  have 
this  problem.  For  instance,  in  the  lambda  calculus  the  function 
f  can  be  written 

>x{x?-2x} 

(the  >  is  a  lambda),  which  can  be  read  "that  function  which  takes 
anv  x  into  x2-3x."  In  the  lambda  calculus,  if  we  have  defined 

f  =  >x{x2-3xl 

and  then  we  ask  the  value  of  ’  f(5)’,  we  can  find  it  by  substitut¬ 


ing  ’  5  '  for 
start  with 


throughout  its  scope.  More  specifically,  we 


when  we  substitute  /x{x2-3x}  tor  'f'  we  get 

/x{x2-3x}  (5) 

Mow,  we  replace  this  expression  by  a  copy  of  the  body  of  f 
(namely  x~-3x)  in  which  everv  free  occurrence  of  ’x'  is  replaced 
by  *5' : 

5?-3-5  =  25-15  =  10 


This  is  called  the  "copy  rule"  for  function  evaluation  because 
the  invocation  ’f(5)'  is  actuallv  replaced  by  a  copy  of  the  body 
of  the  function  with  its  parameter  textually  substituted,  i.e. 


-  ]  3  - 


1 52-3 ' 5  '  . 

1.2.6  syntax  or  the  „ambda  calculus . 

The  lambda  calculus  has  a  very  simple  syntax.  Lambda 
expressions  are  composed  or  the  symbols  '}',  '  (  '  ,  ')' 

and  variable  names,  put  together  according  to  the  loliowmg 
rules: 

(1)  It  'x'  is  a  variable  and  'S'  is  an  expression  ot  the 

lambda  calculus,  tnen  '/x(2}'  is  an  expression  ot  the  lambda  cal¬ 
culus,  called  an  abstraction.  We  call  'x'  the  bind ing  ot  the 
abstraction  and  the  body  ot  the  abstraction. 

(2)  It  ' F *  and  'S'  are  expressions  ot  the  lambda  calculus, 
then  ' F ( E) 1  is  an  expression  ot  the  lambda  calculus,  called  an 
application.  We  call  'F'  the  operator  ot  the  application  and  ' E ' 
the  operand  ot  the  application. 

(3)  It  ' E '  is  an  expression  ot  the  lambda  calculus,  then  so 
is  '  (E)  '  . 

(4)  It  'x'  is  a  variable,  then  it  is  an  expression  ot  the 
lambda  calculus. 

(5)  The  only  lambda  expressions  ate  those  described  m  (1) 
to  (4)  . 

To  permit  mote  meanmgtui  examples,  we  will  sometimes  ai. low 
additional  types  ot  expressions  within  our  lambda  expressions, 
such  as  conventional  arithmetic  expressions  (e.g.  '3+x'). 

The  way  in  which  we  have  described  the  svntax  ot  the  lambda 
calculus  will  form  a  model  tor  all  later  syntax  descr  i  Dt  ions .  ,,Te 
have  enumerated  a  set  of  primitives  (the  basic  symbols  and  vari¬ 
ables)  and  have  described  a  set  of  constructors  or  formation 
rules,  which  will  yield  all  the  legal  expressions  ot  the  lanouage 
when  aoolied  recursively  to  the  Primitives. 

EXERCISES: 

which  of  the  following  are  legal  lambda  calculus  expres¬ 
sions? 

1 .  x 

?.  ffx) 

3  .  >x{  f  (x)  ) 
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4 .  (g) y 

5.  f (a) (b) 

6.  /x{£(x>}  (a) 

7  .  /x{  t  (X)  }  (  /x{x}  ) 

3.  f  g 

9  .  lg (a)  } 
xO.  £  { x } 
lx.  £(/x) 

1.2.7  semantics  o t  the  lambda  calculus . 

In  a  ptevicus  section  we  inter  mail y  discussed  evaluation  ot 
expressions  ot  the  lambda  calculus  by  the  copy  tula.  In  this 
section  this  evaluation  is  detined  more  exactly  through  two 
t  eduction  rules: 

1  ( t enaming ) :  one  expression  may  be  reduced  to  another  by 
cnanging  a  bound  variable  throughout  its  scope  to  any  other  vari¬ 
able  that  does  not  occur  within  that  scope. 

2  (substitution)  :  a  subexpression  ot  the  totm  '/x{E}(A)'  may 
be  reduced  by  replacing  it  by  a  copy  ot  S  in  which  ail  tree 
occurrences  ot  x  are  replaced  by  A,  ptovided  this  does  not  result 
in  any  tree  variables  ot  A  becoming  bound. 

We  can  testate  the  renaming  rule  as  toiiows:  An  expression 
'/x{E}'  may  be  reduced  by  renaming  to  an  expression  '/y{F}', 
where  F  is  obtained  ttom  E  by  rep lacing  ail  tree  occurrences  ot  x 
in  E  by  y.  This  is  only  allowed  it  y  does  not  oegu r  in  E.  For 
example,  suppose  we  wish  to  rename  x  to  u  in  '/x  [  x2+2x+i  ^  .  We 
do  tms  by  changing  to  u  ail  tree  occurrences  ol  x  in  'x^  +  2x  +  i'. 
This  yields  '/u{  u2-2u+i  }  ' .  This  reduction  is  symbolized: 

>x{ x2+2x+l }  =>  /u[u2+2u+i} 

Some  other  reductions  permitted  by  the  renaming  rule  ate: 

/x{x}  =>  /a  { a }  =>  /gig}  =>  >t{t} 

/x{/y{x(y)}}  =>  /t{/y{  t  (y)  }  }  =>  / 1  {/a  ( t  ( a )  }  } 

/x { X+i }  =>  /u{u+x} 

/x  {/y  { x-t-y }  }  =>  /a  l/y  { a  +  y }  }  =>  /a{>b{a+b}} 

Lets  consider  an  illegal  eradication  or  the  renaninn  rule  in 
order  to  better  understand  its  restriction.  Sunoose  we  wish  to 
aoolv  the  renaming  rule  to 
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f  =  Xx{  e-x  }  =  Ax{  ( 2  .  ?  1%  29  .  .  .  )  x  } 

bv  changing  x  to  e.  This  is  not  allowed  since  e  occurs  in 
'e-x'.  We  can  see  that  it  we  did  the  substitution  anywav  we 
would  change  the  meaning  of  the  extiression: 

f  =  >e{  e‘e  }  =  >,ef  e2  1 

Mote  that  f  (1)  =  2.71329...  while  t  *  C 1 )  =  1;  f  and  t'  are  not  the 
same  function.  Renaming  x  to  y,  however,  would  not  change  the 
neaninq: 

t"  =  >yf  e-y  1;  f'fl)  =  2.718  29... 

The  renaming  rule  is  generally  needed  only  to  avoid  variable  col¬ 
lisions. 

EXERCISES: 


^ooly  the  renaming  rule  as  indicated,  or  state  that  its 
apolication  would  be  illegal: 

1.  /xfx};  change  x  =>  y. 

2.  /x{>y{x+yH;  change  y  =>  x. 

3.  >x{f(x)};  change  f  =>  g. 

4.  /d{d+el;  change  d  =>  e. 

5.  /x{>y (x  (y)  }  }  ;  chance  x  =>  f. 

Next  we  will  consider  the  substitution  rule.  The  expression 
’>xfx+l} (3) '  tits  the  form  required  by  the  substitution  rule:  it 
is  an  aoolication  whose  coerator  is  an  abstraction.  Renee,  we 
can  reduce  it  by  redacing  all  free  occurrences  of  'x'  in  'x+l' 
by  '3'.  The  result  is  '3+1'.  Now  consider 

>x{  >v{x  (y)  1  1(f) 

This  is  an  aoolication  whose  ooerator  is  the  abstraction 

>xf  >yfx  (y)  }  1 

We  can  aoplv  the  substitution  rule  bv  reDlacing  by  *  t '  all  free 
occurrences  of  'x'  in  'Xy{x(y)l'.  This  oroduces: 


Xy { f  ( y ) > 


IPKWB 
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To  better  understand  the  restriction  on  the  substitution 
rule,  tirst  consider  this  legal  substitution:  Suppose,  as  is 
usual,  that  e*2. 71828  ...  .  Let  f  =  Ax  (Ay { x+v} } .  Then  we  can 
reduce  f(2e)(l)  as  tollows: 

f(2e)(l)  =  ">  Ax{Ay{x+y} }  (2el  (11 

=»>  Ay{  2e+y  HI) 

=>  2e+l  =>  5.43. ..+1  =>  8.43... 

Mow  lets  look  at  a  slightly  different  examole: 

f  '  (  2e )  ( 1 )  where  f’  *>d{>e{d+e>> 

We  see  that  t '  is  the  same  function  as  f;  we  have  just  renamed  x 

and  v  to  d  and  e.  when  we  replace  f’  by  its  value  we  get 

Ad{>e{d+eH  (2e)  m 

which  is  an  application  whose  operator  is  the  abstraction: 

Ad  fAe{d+e  1  1 

To  apply  the  substitution  rule  we  must  replace  all  free 
occurrences  of  *e'  in  ’Ae{d+e}'  bv  '2e*.  ^ut,  this  is  only 
allowed  if  it  does  not  cause  a  free  variable  of  ’2e'  to  become 

bound.  In  this  case  a  collision  does  occur,  since  ’e’  is  tree  in 

‘ 2e '  but  not  in  'Aefd+e}'.  To  see  the  reason  tor  this  restric¬ 
tion  we  will  qo  ahead  and  perform  the  substitution,  "he  result 
will  be  'Ae ( 7e+e } ' .  This  has  changed  the  meaning  of  the  expres¬ 
sion;  a  fact  we  can  see  by  evaluating: 

Ae{2e+e}fl)  =>  2-1+1  =>  3 

Hence,  f '  (2e)  (1)  =>  3 

although  we  know  the  answer  should  be  6.43....  How  do  we  avoid 
this  situation?  Since  bound  variables  are  arbitrarv,  we  simply 
rename  the  offending  bound  variable.  ffor  instance,  we  can  rename 
' e '  to  ' c ' : 


Ad(Asfd+e}}  (2e)  (11  =>  Ad  f  Ac  { d+c  }  H  2e )  f  1 ) 


which  lets  us  proceed  with  the  reduction: 


Ad{  Ac{d+c}  }(2e)  (1)  =>  Ac  { 2e+c  1(1) 

=>  2e+l  =>  5.43. ..+1  =>  6.43... 


In  tact. 


this  is  the  major  use  of 


the  renaming  rule. 


HXSRCISRS: 
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Determine  if  che  substitution  trule  is  applicable  to  each  of 
these  expressions.  It  so,  reduce  the  expression  by  the  substitu¬ 
tion  rule,  tirst  aoolyina  the  renaming  rule,  it  necessary. 

1  .  >x{x  (y)  >  (t) 

2  .  >xf  Av{x  (v)  )  1  'y) 

3.  f  ( 3 ) 

4.  /xf  Ay{x(y)>  }(  Xzfv(z)}  ) 

5.  >yfyy}  (j) 

3.  >f  {  f  (3)+f  (4)  1  (g) 

1.7.3  reduced  form. 

If  and  when  an  expression  is  reduced  to  the  extent  that  che 
substitution  rule  can  no  longer  be  applied  to  it,  it  is  said  to 
be  in  reduced  form.  Intuitively,  an  expression  is  in  reduced 
form  when  it  is  an  answer  (i.e.  it  is  done  computing).  The  fol¬ 
lowing  table  shows  examples  of  both  unreduced  and  reduced  expres- 
s ions : 


Mot  Reduced 

Reduced 

Ax{x}  fv) 

Y 

Ay {£  (y)  }  (a) 

£  (a) 

Ax(  Ay{x  (v)  }  }  (t) 

Ay  f  f  (y) } 

Ax  fx  H  Ax  f  x }  ) 

Axfx} 

Axfx  (y)  }  (  Axfx  (x)  }  ) 

Y  (y) 

In  each  case  above,  the  expression  on  the  right  is  the  reduction 
of  the  expression  on  the  left.  Mot  all  expressions  have  a 
reduced  form.  Consider  the  expression  Y  (Y)  ,  where  Y  =  Ax{x(x)}: 

Y  (Y)  =>  *x{x  (X) }  (Y)  =>  Y(Y)  =>  ... 

This  is  the  lambda  calculus  equivalent  of  an  infinite  loop. 

RXPRCISES: 

Decide  it  each  of  the  following  expressions  is  in  reduced 
form.  It  not,  then  reduce  it  to  reduced  form. 

1.  >f  {  t  (3)  +£  (4)  }  (  Ay(yy)  ) 

2  .  f  (  Ax  { x+x  }  ) 
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3.  (  >x{x+l)  ) 

4.  *xfx<01  (  >x(x+l!  (3)  ) 

I . 2 . Q  mult inle  parameters  and  other  abbreviations . 

The  lambda  expressions  we  have  defined  have  only  one  bound 
variable.  We  can  get  the  eftect  of  two  bound  variables  by  nest¬ 
ing  the  lambda  expressions,  for  instance: 

>x{>y[x+y)  1  (3)  (1) 

=  >  >yf3+y}(i) 

=  >  3+1 

=  >  4 

Because  such  nested  lambda  expressions  are  so  common,  we  allow 
the  following  abbreviations  (using  ’=>'  also  as  a  sign  of  abbre¬ 
viation)  : 

>kxy{x+y)  =>  XxOyfx+vH 
F (3 ,1)  =>  F  ( 3 )  (1) 

These  abbreviations  are  the  usual  method  of  handling  multi- 
argument  functions  in  the  lambda  calculus.  Ot  course,  it  is  not 
normally  necessary  to  think  of  these  as  abbreviations;  we  just  do 
the  multiple  parameter  substitutions  directly,  e.g., 

if  f  =  >xv{x+y) 
then  f  (  3  , 1 ) 

/7V\ 

=  >  >xyfx+y}  (3,1) 

=>  3+1  =>  ^ 

In  exactly  the  same  way  we  will  allow  substitutions  involving  any 
number  of  parameters,  including  none. 

>abc [ax^+bx+c } (9 , 5 , 1 )  =>  9x2+Bx+l 

>{m+ll ()  =>  m+1 

“is  we  have  seen  in  some  of  the  Previous  examples,  lambda  expres¬ 
sions  can  get  quite  large.  In  order  to  be  able  to  program  signi¬ 
ficant  functions  in  the  lambda  calculus  we  will  need  a  way  of 
attaching  names  to  lambda  expressions.  Therfore  we  will  allow 
rewriting  rules  ot  the  form: 

pluso  *>  >,xfx>0} 

minuso  =>  >x{x<0) 

succ  *>  >x{x+l) 

square  =>  /x{x*x} 


f 


in  .i|i  ia»OTPiwi|) 
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Then  we  can  write,  tor  instance, 

minusD (succ (2) ) 

=>  >x{x<0)  (succ (2)  ) 

*>  succ  (2) <0 
=  >  >x{x+l 1  (2) <0 
=>  2+l<0 

=  >  3<0 

=>  false 

1 .2.10  the  Church-Rosser  property. 


In  the  above  reduction  we  reduced  the  outermost  amolication 
first.  We  need  not  have  done  this,  for  instance, 

minuso (succ (2) ) 

=  >  mi  nusp  0.x  { x+i  }  (2)  ) 

=>  minusp(2+l) 

=>  minusp{3) 

=>  >x { x <0 }  (31 
=  >  3<0 

=>  false 


we  see  that  this  produces  the  same  answer.  It  is  a  property  of 
the  Dure  lambda  calculus  (called  the  Church-Rosser  property)  that 
any  reduction  sequence  that  terminates  will  produce  the  same 
result.  It  is  important  to  know  when  a  lanouage,  or  a  part  of  a 
language,  satisfies  the  Church-Rosser  Property  since  this  means 
an  optimizing  compiler  can  alter  the  evaluation  order  without 
effecting  the  meaning  of  a  program.  Since  some  of  the  extensions 
of  the  lambda  calculus  that  we  will  be  investigating  do  not 
satisfv  the  Church-Rosser  property,  we  will  adopt  a  standard 
order  for  reduction.  It  is  defined  by  the  rule:  don't  reduce  an 
application  until  its  arguments  are  already  in  reduced  form. 

STANDARD  REDUCTION  ORDER:  An  application  is  reduced 
(by  substitution)  only  if  its  arguments  are  already 
in  reduced  form. 


EXERCISE :  Reduce  to  reduced  form: 

>f {succ  (f  ( 2 )  +1  '3)  )  }  (/x{square(x)+2)  ) 


EXERCISE :  Suppose  the  following  definitions  are  given: 
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7ero  =>  >tc(c) 

One  =>  >tc { t  (c) > 

Two  =v>  /tcff(t(c))> 

Three  =>  >tc{f (c  (f (c) ) ) } 

sun  =>  /MN f/tc {*  (f ,M ( t . c) ) H 

then,  reduce  to  reduced  corn  ' sum (Two , One ) ' .  '’'hat  is  this  equal 
to?  It  you  wonder  about  the  motivation  tor  these  definitions, 
then  try  reducing  ’ Th ree (succ , 0 ) '  and  ’ Two (succ , 3 ) ' . 


Chapter  3 


I.?  Th e  Extended  Lambda  Calculus ■ 

I-3-1  Conditionals . 

Che  lambda-calculus,  as  ve  have  been  us  ins  it  so  far,  is  .not 
very  useful;  it  is  only  possible  to  define  functions  that  evalu¬ 
ate  strictly  in  order:  there  is  no  decision  making  ability. 
Therefore  we  would  like  to  define  a  function  'if  such  that 
if(c.t.f)  =>  t  if  c  is  true  and  if(c,t,f)  =>  f  if  c  is  false. 
Eence ,  'true'  selects  'f  from  (t,f)  and  ’false'  selects  ’f  from 
(t,f).  One  way  to  do  this  is  to  define  'true'  and  'false'  so 
that  true(t.f)  =>  t  and  false(t,f)  =>  f.  Thus: 

true  =>  Atf  1 1  > 
false  =>  Jvtfifl 

Then  we  want  if(c.t.f)  =>  c(t,f),  where  c  reduces  to  true  or 
false,  so 

if  =>  Abtffb(t.f)! 

To  see  how  this  works,  suppose  'x=y'  returns  'true'  if  x  equals  y 


fal 

se’ 

otherwise . 

Then 

.•  w 

2=0 

,  25,  3" 

) 

=  > 

if  ( 

false , 

25. 

J  r-r  \ 

=  > 

Abt 

f  { b  { t ,  f } 

}  : 

false 

=  > 

fal 

3e(  25, 

yn ) 

=  > 

A  tf 

1 f | (  25 , 

'37' 

) 

=  > 

3^ 

we 

will 

nrogram 

th* 

;  logi 

'not'.  Tot  is  the  simplest  since  it  just  negates  a  truth  value: 

not(true)  =  >  false 
not(false)  =>  true 

That  is,  if  x  i3  true  then  not(x)  is  false,  otherwise  not(x)  is 
true.  This  can  be  directly  translated  to  the  lambda  calculus: 

not  =>  Ax!  if(  x,  false,  true  )  } 

The  'and'  function  is  defined  so  that  and(x,y)  is  true  only  if 
both  x  and  y  are  true.  This  is  summarized  in  the  following  truth 


We  can  see  that  if  x  is  true  then 
7.  and  that  if  x  is  false  then 
the  value  of  .7.  We  can  translate 
calculus : 


and ( x ,7 )  has  the  sate  value  as 
and(x,y)  is  false  regardless  of 
this  directly  into  the  lambda 


and  =>  x.xy f  if'  x.  7,  false  )  ! 


7  or  both 


Define  ’or 
are  true. 


sc  that  orfx.y)  is  true  if  and  only 
That  is,  'or*  must  satisfy  the  truth 


if  x 
fable 


n  r» 


OR 

true 

false 

true 

true 

true 

false  | 

true 

f  alse 

Show  that  your  definition  works  by  reducing  'or (false 
I.3.2  Recursive  Definitions. 


true  ) 


Wow  that  we  have  a  conditional,  we 
useful  functions.  The  factorial  function 


can  define  some 
is  defined  so  t h a 


1 !  =  4- '  3 ' 2 ' 1  =  24 

3!  =  3-2-1  =  6 

0!  =  1 

or  in  general. 

n!  =  n(n-1 ) (n-2) ... (2) ( 1 ) 

The  factorial  can  also  be  defined  recursively  as  follows: 

n !  =  1 ,  if  n=0 

n(n-1 ) f ,  if  n>0 

'Jsing  the  conditional  it  is  now  easy  to  define  a  function 
such  that  fac(n)  =  n!. 

fac  =>  )inf  if(  r.=0 ,  1  ,  n  "  fac(n-1  )  )  ' 


Consider  the  computation  of  fac(2): 
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f ac ( 2  ) 


=  > 

An* 

iff 

n=0,  1,  n*facfn-l)1  !  '2) 

=  > 

if' 

2=0, 

1 .  2*f  ac ( 2-1 ) ) 

=  > 

if  ( 

false,  1 ,  2*f  ac ( 1 )} 

=> 

2*f ! 

ac  ( 1  ) 

=  > 

2  * 

An! 

iff  n=Q .  1,  n*fac( n-1 ) )  *  ( 

=  > 

2  * 

iff 

1=0,  1 ,  1 *fac( 1 -1 )  ) 

=  > 

2  * 

1  * 

fac(O) 

=  > 

2  * 

1  * 

Anj  iff  n=0,  1,  n*fac(n-l)) 

=> 

2  * 

1  * 

iff  0=0,  1 ,  0*fac(0-1 ) ) 

=  > 

2  * 

1  * 

if(  true,  1,  0*fac(-1)) 

=  > 

2  * 

1  * 

1 

=> 

=  > 

2  * 
2 

1 

To  keep  the  above  reduction  readable,  most  of  the  reductions 
associated  with  'if  have  not  been  shown.  Notice  that  in  the 
fourth  to  the  last  line  (the  last  line  with  an  'if  in  it;  if  we 
had  decided  to  reduce  the  argument  formula  C*fac(-1 )  we  would 
have  started  a  never-ending  recursion.  That  is, 


2  * 

1 

* 

4  -P  ( 

0=0.  1,  0*fac(0- 

1  ) } 

=  > 

2 

* 

1  * 

if(  true,  i,  0*fac(-l)) 

=  > 

2 

* 

«  * 

if;  true ,  1  ,  0  * 

An!  if(  n=0. 

1  .  n*f ac ( n-1  ) ) !  (-1  ) 

=  > 

2 

* 

1  * 

iff  true ,  1,0* 

if(  -1=0.  1  , 

-1  *  A.n!  if(  .n=0 

,  1 ,  n*fac ( n- 

1))  ) ( -2 )  )) 

=  > 

2 

-* 

1  * 

if (  true ,1,0* 

if(  false,  1 

-1  *  if (  -2=0,  1 

.  -2*fac (-2-1 

)  ))) 

=  > 

process 

may 

never  terminate! 

Whau  “tha 

Church-Fosser  pro- 

party  really  says  is  that  two  different  reductions  of  a  formula 
give  the  same  result  provided  they  both  terminate .  For  this  rea¬ 
son  we  avoid  evaluating  any  arguments  "of  'if'  that  we  don't  have 
to . 

Since  'if'  is  such  a  common  function,  we  will  introduce  a 
special  notation  for  it.  This  is  just  an  abbreviation,  it  really 
adds  nothing  to  the  lambda  calculus.  Such  abbreviations  are 
often  called  "syntactic  sugar"  (because  a  little  "syntactic 
sugar"  helps  one  to  swallow  the  lambda  calculus).  For  simple 
'if’s,  3uch  as  if(b,t,e)  we  will  write  [b->t!e],  which  is  read: 
"if  b  then  t  else  e."  For  nested  'if’s,  such  as  if(b,  t,  if(c.  u. 
e )  ">  we  will  write 

[  b  ->  t  |  c  ->  u  I  e  ] 

and  30  forth.  This  can  be  read  "if  b  then  t  else  if  c  then  u 
else  e".  Using  this  notation  the  factorial  function  can  be 
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*y  r»  n  +  +  £*  o 

fac  =  >  /n!  rn=0  ->  1  I  n'fac(n-l)  ]  ’ 

I.7.3  Primitives . 

We  have  seen  that  it  is  possible  to  iefine  in  the  lam 
calculus  Boolean  values  ''true  and  false',  logical  connectiv 
’if’  expressions,  arithmetic  (sum),  and  even  numbers  themselves. 
Phis  should  lend  some  credibility  to  the  statement  made  earlier 
that  anything  that  can  be  done  on  a  computer  can  be  done  in  the 
lambda  calculus.  For  our  purposes,  there  is  not  much  point  in 
carrying  this  exercise  any  further.  In  the  future,  any 
application-oriented  functions  that  we  might  need  'such  as  arith¬ 
metic'  will  be  introduced  as  extensions  to  the  lambda  calculus. 
For  instance,  the  arithmetic  operations  might  be  introduced  by  a 
set  of  rules  like: 

sum( 1,1)  =>  2 

sum' 1,2)  =>  3 


or  in  general 

sun(n,n)  =>  m+n 

Phis  way  we  have  an  application  independent  language  framework 
formed  by  the  lambda  abstraction  and  function  application  svntax, 
and  a  flexible  set  of  application  dependent  orimitive  operations 
which  we  can  define  as  the  need  occurs.  Notice  that  again  we  are 
breaking  the  language  down  into  primitives  and  constructors .  In 
the  next  section  we  will  build  a  list  processing  language  by  com¬ 
bining  the  constructors  of  the  lambda  calculus  with  a  set  cf 
powerful  list  processing  primitives.  We  will  find  that  many 
apparantly  different  programming  languages  are  really  just 
sugared  versions  of  the  lambda  calculus  with  some  application- 
oriented  primitives  added.  Phe  following  chart  shows  some  primi¬ 
tives  that  might  be  included  in  languages  intended  for  numerical, 
list  processing,  string  processing  and  data  processing  appiica- 
t ions . 


I 


Q> 
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!  language 

constructors 

orimitives 

application 

independent 

aDplication 

dependent  j 

numerical 

Axul,  :Ui 

integers,  reals, 

+ ,  - ,  x .  ! .  ... 

list  orocessing 

1 

>.  x  i  B  i  .  f  ^  a ) 

lists  ,  atoms , 

first,  rest,  cons ,  ... 

string  processing j 

AxjF!,  f  ( a) 

strings,  characters, 
substr,  concat,  match,  ... 

data  processing  j  AxjZf,  f(a) 

i  *  i  ! 

files,  records, 
move,  read,  write,  ... 

1-3-4-  Data  Types . 


When  we  extend  the  lambda  calculus  with  new  primitives  we 
will  always  do  it  by  defining  a  set  of  data  values  and  a  set  of 
pr iaitive  operations  on  those  values.  Any  operations  we  wish  to 
perform  on  the  data  values  must  be  constructed  from  the  primitive 
operations.  The  term  data  type  is  used  to  refer  to  a  set  of  data 
values  together  with  a  set  of  primitive  operations  on  those 
values.  For  instance,  the  data  type  integer  is  the  set  of 
integer  data  values: 

• • . ,  -3,  -2,  -1 ,  0,  1 .  2,  3,  ... 


together  with  the  nrimitive  operations  on  those  values,  e.g., 

,  “ *  x,  / ,  — ,  ^ ^ y 


Any  other  operation,  e.g.  squaring,  must  be  constructed  from  the 
given  values  and  primitive  operations: 


square 


An{  nxn  ! 


Similarly,  the  Boolean  data  type  is  composed  of  the  Boolean 
values : 

true,  false 

together  with  the  primitive  operations  on  these  values: 

not,  and,  or,  if,  =,  ^ 


1.3-5  The  list  Data  Type . 

In  this  section  we  will  define  the  list  data  type.  The  lata 
values  are  called  lists  and  are  written  as  sequences  of  values 
surrounded  by  angle  brackets.  For  instance, 
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<5  3  1 6> 


is  a  list  containing  the  integers  five,  eisht  an!  sixteen,  in 
that  order.  Lists  can  have  any  number  of  elements,  including 
one : 

<32> 

This  is  the  list  containing  only  the  integer  32.  Lists  can  also 
be  empty,  i.e.,  have  no  elements: 

<> 

This  is  called  the  null  list .  Lists  can  contain  anv  iata  values, 
for  instance, 

<5  ' cat '  false  1 . 6> 

is  a  list  vhose  first  element  is  the  integer  five,  vhose  second 
element  is  the  string  'cat',  vhose  third  element  is  the  Boolean 
value  false,  and  vhose  fourth  and  last  element  is  the  real  number 
1.6.  Lists  can  also  contain  other  lists,  for  instance, 


<5  <9  32>  3  1 6> 

is  a  list  vhose  first  element  is  the  integer  five,  vhose  second 
element  is  the  list  <9  32>,  vhose  third  and  fourth  elements  are  3 
and  16.  Lists  can  be  nested  in  this  vay  to  any  depth. 

We  will  define  three  important  primitive  operations  on 
lists.  The  function  'first'  returns  the  first  element  of  a  list. 

f irst(  <5  3  1 6>  )  =>  5 

first (  <<1  2>  <3  4>>  )  =>  <1  2> 

In  the  second  example  notice  that  the  first  element  of  <<1  2>  <3 

4>>  is  the  list  <1  2>.  It  makes  no  sense  to  apply  'first'  to  the 
null  list  or  to  an  atom ,  which  is  what  we  call  things  that  are 
not  lists: 

first1'  <>  )  is  meaningless 
first(  13  )  is  meaningless 

!Tull  lists  and  atoms  don't  have  a  first  element. 

A  complementary  operation  to  'first'  is  'rest',  which 
returns  all  of  a  list  except  the  first  element,  e . g . . 


-  27  - 


rest (  <5  3  15>  )  =>  <3  16> 

rest (  <<1  2 >  <3  4>>  )  =>  <<3  4>> 

rest(  <3>  )  =>  <> 

It  makes  no  sense  to  apply  'rest'  to  null  lists  or  atoms: 

rest(  <>  )  is  meaningless 
rest(  13  )  is  meaningless 

The  'first'  and  'rest'  operations  take  lists  acart;  we  need 
another  operation  to  put  them  together-  This  is  'cons'  (short 
for  "construct"),  which  makes  its  first  argument  the  new  first 
element  of  the  list  which  is  its  second  argument.  por  instance, 

cons (  5 ,  <3  1 5>  )  =>  <5  3  1 6> 

cons (  <1  2>,  <<3  4>>  )  =>  <<1  2><3  4» 

cons (  <5> ,  <5  i S>  )  =>  <<5>  3  1 6 > 

cons (  5,  <>  )  =>  <5> 

Notice  that  the  first  argument  to  'cons'  does  not  have  to  be  an 
atom,  although  its  second  argument  does  have  to  be  a  list: 

cons(  5,3)  is  meaningless 

The  meaning  of  'first',  'rest'  and  'cons’  is  summarized  in  the 
following  formulas.  In  these,  'x'  represents  any  data  value. 

first(  <x  . . . >  )  =>  x 

rest (  <x  . . . >  )  =>  <...> 

cons(  x,  < . . . >  )  =>  <x  . . . > 

These  operations  can  be  combined,  for  instance, 

first(  rest(  <5  3  16>  )  ) 

=  >  first(  <3  1 5 >  ) 

=  >  3 

Hence,  first ( rest(L) )  is  the  second  element  of  1. 

The  'cons’  operation  is  the  inverse  of  'first'  and  'rest'. 
For  example,  since 

first(  <5  3  16>  )  =>  5,  and 

rest(  <5  3  15>  )  =>  <3  15>,  and 

cons(  5.  <3  16>  }  =>  <5  3  1 6 > 


we  see  that 
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cons  (  first '  <5  3  'l6>),  rest '<3  3  16>) 

=  >  cons (  5 ,  <3  1 6 >  ) 

=  >  <5  3  1 6 > 

Thus,  the  following  identities  hold  'where  1  is  a  list  and  x  is 
any  value): 

f  irst  ( cons ( x ,  !''  )  =  x 
rest ( cons ( x , 1 ) ^  =  1 

cons (  first  (L) ,  rest  ( l) )  =  Z»  if  1  is  non-null 

Another  primitive  that  will  he  useful  to  us  is  the  equality  rela¬ 
tion.  For  instance. 

5=5  =>  true 

5=6  =>  false 

The  equality  relation  is  only  defined  for  atoms  (e.g.,  numbers, 
strings  and  Foolean  values);  its  use  on  lists  is  meaningless: 

5=<6>  is  meaningless 

The  meaning  of  the  equality  relation  is  summarized  by  the  follow¬ 
ing  formulas,  in  which  'a'  and  'V  represent  different  atoms: 

a=a  =>  true 
a=b  =>  false 

There  are  only  two  other  functions  that  we  need  to  do  useful  list 
processing.  These  are  'null',  which  asks  if  a  list  is  empty,  and 
'atom',  which  asks  whether  something  is  a  list.  For  instance, 

null(  <>  )  =>  true 

null(  <5  3  1 S>  )  =>  false 

null(  <<>>  )  =>  false 

The  list  <<>>  is  not  null  because  it  contains  a  single  element, 
namely,  the  null  list,  <>.  The  'null'  function  is  not  iefined 
for  atoms: 

null(5)  is  meaningless 

Hull  is  defined  by  the  following  formulas,  in  which  x  is  any 
value : 

null(  <>  )  =>  true 
null(  <x  ...>  )  =>  false 

The  'atom'  function  determines  whether  a  value  is  an  atom  or  a 
li3t,  for  example, 


at ora (  5  '  =  >  true 

atom(  <5  S  1 5>  ^  =>  false 

atom(  <5>  )  =>  false 

atojn(  <>  )  =>  false 

The  'atom'  function,  which  is  meaningful  when  applied  to  any 
values,  is  defined  by  the  following  formulas,  in  which  'a' 
represents  any  atom: 

atom(  )  =>  false 

atom(  a  )  =>  true 

The  list  data  tyne  is  summarized  in  the  following  figure. 

Data  Values: 

atoms:  1,  2,  ...»  'cat',  'hat',  ....  true,  false,  .... 

lists:  <>,  <1  ' cat ' > ,  <’call'  < ' var '  ' f ’ >  23> . 

Primitive  Operations: 


first ( 

<  X 

...>  )  => 

X 

rest( 

<x  . 

. . >  )  => 

<  .  .  .  > 

cons  ( 

X.  < 

.  .  .>  >  => 

<x  .  . 

a=a 

=> 

true 

a=a' 

=> 

false 

null  ( 

<>  ) 

=>  true 

null  ( 

<  X  . 

. .>  )  => 

false 

atom( 

a  ) 

=>  true 

atora( 

<  .  .  . 

>  )  =>  f 

alse 

where  a  is  an  atom  and  x  is  a  list  or  an  a*om. 

Figure  1  .  The  List  Data  Type _ _ _ 

1.3,6  Recursive  Problem  Solving. 

In  order  to  better  understand  these  list  processing  opera¬ 
tions,  a  number  of  examples  will  be  presented.  First  we  will 
define  a  function  'sub'  such  that  sub(L,i)  is  the  i-th  element  of 
the  list  L.  For  instance, 

sub (  <5  3  16  25>,  3  )  =>  16 

sub (  <5  <9  32>  1 6> ,  2  )  =>  <9  32> 

since  <9  32>  is  the  second  element  of  <5  <9  32>  16>.  How  are  we 
going  to  program  this  function?  The  way  to  solve  problems  like 
fhi3~i3  to  ask  what  subcases  of  the  problem  are  already  solved. 
In  the  case  of  'sub'  this  is  fairly  easy,  since  by  definition 


,sub(L,1')'  is  just  the  first  element  of  1.  That  is, 

sub(I,1)  =>  first(l) 

The  next  step  in  solving  a  problem  such  as  this  is  to  find  some 
way  to  reduce  the  general  problem  to  the  subcases  that  are 
already  solved.  notice  that 

sub (  <5316  25> ,  5  )  =>  IS 
sub'  <3  16  25>,  2  )  =>  16 

Hence , 

sub(L.i)  =>  sub(  rest(L) ,  i-1  } 

He  have  reduced  the  original  problem,  sub(l,i),  to  one  that  is 
closer  to  the  solved  problem,  sub(L,1),  since  i-1  is  closer  to  1 
than  i  is.  We  now  have  two  cases,  just  as  in  the  factorial  exam¬ 
ple  : 

sub(L,i)  =>  first(L),  if  i=1 

sub(L,i)  =>  sub(  rest(lx,  i-1  ),  if  i>1 

This  is  easily  translated  to  the  lambda  calculus: 

sub  =>  >, I> i }  [  i  =  1  ->  first(l)  I  sub (  rest '  1 ),  i-1  )  ]  ! 

We  will  try  this  on  sub(  <A  3  C  D> ,  3): 

sub(<A  3  C  D>,  3) 

=  >  Ali!  '  i  =  1  ->  first(L)  I  sub(  rest(l)  ,  i-1  )  ]  }(<A  3  C  3> . 
=>  T  3=1  ->  first (<A  3  C  D> )  !  sub(rest(<A  3  T  D>),3-1)  1 
=  >  sub ( <3  T  D>  ,  2) 

=  >  r  2=1  ->  f irstC <3  C  D>)  (  sub(rest(<3  0  D> ) .2-1 )  1 
=  >  sub( <C  D>  .  1  ) 

=>  r  1=1  ->  f irst ( <C  D> 1  I  sub( rest ( <C  3>),  1-1}  ] 

=>  first( <C  D> ) 

=  >  C 

The  'sub'  function  is  so  useful  that  we  will  adopt  a  special 
"array  subscripting"  notation  for  it: 

A[ i ]  =>  sub(A.i) 

Thus,  A T 1 ]  and  first(A)  are  the  same. 

Next  we  will  define  a  function  'append'  such  that 

append(L,?d)  concatenates  the  lists  1  and  Id.  That  is, 


append(  <1  2> ,  <3  4-  5>)  =>  <1  2  3  4  5> 


'lots  that  this  is  different  from  cons(<l  2>,<3  4-  5>)  which  would 
give  us  <<1  2>  3  1  5^-  We  will  use  the  same  problem  solvin 
technique  that  we  used  with  ’sub’  by  asking:  What  cases  o 
’ append ’  are  immediately  solvable?  Those  in  which  one  of  th 
lists  to  be  apnended  is  null,  for  instance, 

append(  <>,  <4  5  S>  )  =>  <4  5  6> 

In  general, 

append(  <>,  L  )  =>  1 

append!  1,  <>  )  =>  L 

-Text  we  must  investigate  how  the  general  problem  can  be  reduced 
to  either  of  these  two  cases.  For  instance,  since  we  know 
append (<>,L)  is  L,  we  can  work  on  reducing  the  first  argument  to 
an  empty  list.  Suppose  we  wish  to  simplify 

append(  <2>,  <3  4  5>  ) 

We  know 

aocend!  <>,  <3  4  5>  )  =>  <3  4  5> 

cons (  2,  <3  4  5>  )  =>  <234  5> 

so  we  can  see  that 

append!!  <2>,  <3  4  5>  ) 

=  >  cons(  2,  <3  4  5>  ) 

=  >  cons!  2,  append(  <>,  <M  5>  )) 

'Tow  let’s  consider  a  more  complicated  example: 

append(  <1  2>,  <3  4  5>  ) 

We  already  know  how  to  do 

append (  <2>.  <3  4  5>  )  =>  <234  5> 

so  all  we  have  to  do  is  reduce  the  new  case  to  this: 

aopend!  <1  2>,  <3  4  5>  ) 

=>  cons (  1 ,  <2  3  4  5>  ) 

=>  cons(  1 .  append!  <2>,  <3  4  5>  )) 

Summarizing,  we  have 

append!  <1  2>,  <3  4  5>  )  =>  cons!  1,  append!  <2>,  <3  4  5> 
append!  <2>,  <3  4  5>  )  =>  cons!  2,  append^  <>,  <3  4  5> 


a> 
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It  should  be  aooarent  that 


the  general  case  is 


append'x,;/)  =  cons(  x[l],  append'  rest(x),  y  )', 


Summarizing,  we  have  the  two  cases: 
append' x,. v )  =  >  y, 

appendix, 7)  =>  cong(x[l ] ,  append ( rest ( x^ ,7) ) , 


if  x  is  null 
if  x  is  non-nul 


This  can  be  eas 


I7  translated  to  the  lambda  calculus: 


append  =>  xy  S 


null(x)  ->  7 

cons(  x[l],  append'  rest(x',  y)  ) 


! 


W e  will  find  that  all  recursive  definitions  fit  this  pattern:  '1) 
a  stooping  condition  that  forms  the  base  of  the  recursion  and  (2) 
a  recursive  invocation  of  the  function  in  which  the  problem  is 
reduced  to  a  simpler  problem-  In  list  processing  the  stopping 
condition  often  takes  the  form  ’null'...)',  just  as  in  numerical 
functions  it  often  fakes  the  form  '...=0'.  You  probably  will 
recognize  a  similarity  between  recursive  functions  and  mathemati¬ 
cal  proofs  by  induction.  This  similarity  simplifies  prooving 
that  recursive  functions  are  correct. 


It  should  be  mentioned  that  if  we  had  decided  to  reduce  the 
second  argument  to  the  null  list  rather  than  the  first,  we  would 
have  found  the  going  much  tougher.  The  list  processing  primi¬ 
tives  favor  working  on  the  beginning  of  a  list,  hence  the  first 
argument  of  ’append’.  This  sort  of  intuition  comes  from  practice 
with  using  the  primitives. 


Although  it  is  relatively  easy  to  prove  that  ’append’  is 
correct,  we  will  convince  ourselves  by  working  the  reduction  of 
append ( < 1  2>,<3  1  5>)  . 


aonend(<i  2>,<3  1  5>) 

=>  r  null ( < 1  2> )  ->  <3  1  5> 


=  > 
=  > 

=  > 
=  > 
=  > 
=  > 
=  > 


!  cons'  <1  2>[l],  append'  rest(<1  2>),  <3 
consul  ,  append(<2>,  <3  4  5>)) 
cons(1,  [  null(<2>)  ->  ... 

I  cons ( <2> [ 1 ] . append (rest(<2>) .  <3 
con3(  1,  cons(2,  append'O,  <J  4  5>)  )) 
cons'l,  cons(2.  [null'O)  ->  <3  4  5>  I  •• 
cons(l,  cons(2.  <3  4  5>  )) 
cons ( 1  ,  <2  3  4  5>  ) 

<1  2  3  4  5> 


A  5  >  )  )  ] 


As  final  example 
returns  ’true’ 

' i . e .  have  the  3 


,  we  will  define  the  function 
if  its  two  arguments  are  equal 
ame  structure).  (Recall  that  ’=’ 


’equal’  which 
atoms  or  lists 
only  works  on 


0 


M  C)  ifl  r-l  -P  Jl  C  O  I— t 
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atoms,  hence  it  cannot  be  used  to  compare  lists.)  That  is 

equal (  <5  <3  16>  25>,  <5  <3  1S>  25>  )  =>  true 

equal (  <5  <3  16>  25>,  <5  <8>  16  25>  )  =>  false 

As  in  the  previous  examples,  the  stopping  point  of  our  recursion 
will  be  those  cases  that  we  can  already  solve.  Then,  we  will 
attempt  to  reduce  the  general  case  to  these  simpler  cases.  A 

good  place  to  begin  in  any  list  processing  problem  is  the  null 

list,  and  this  is  the  case  here;  ali  null  lists  are  equal: 

equal(  <>,  <>  )  =>  true 


Another  good  place  to  begin  in  list  processing  is  with  atoms. 
This  is  particularly  true  in  this  case,  since  the  '=’  relation 
can  be  used  to  test  equality  of  atoms.  Tor  example, 

equal(5,5)  =>  5=5  =  >  true 
equal(5,6)  =>  5=6  =>  false 

These  cases  can  be  written  more  generally: 

equal(x,y)  =>  true,  if  x  and  y  are  both  null 
equal  (x,. 7)  =>  false,  if  x  or  y  is  null,  but  not  both 

equal (x,y)  =>  true,  if  x  and  y  are  atoms  and  x=y 
equal (x,y)  =>  false,  if  x  and  y  are  atoms  and  x^.y 
equal(x,y)  =>  false,  if  x  or  y  is  an  atom,  but  not  both 


t  remains  to  reduce  the  general  case  to  these  solved  cases, 
onsiier  ' equal ( x ,y ) ' ,  where  x  and  y  are  non-null  lists  (if  they 
ren't  then  the  problem  is  solved).  How,  if  x  and  y  are  non-null 
ists,  what  are  the  conditions  that  must  be  satisfied  to  make 
hem  equal?  Clearly,  they  must  have  the  same  number  of  elements 
nd  each  of  their  elements  must  be  'equal'.  Since  both  lists  are 
on-null  we  know  that  they  both  have  a  first  element.  Hence,  we 
an  compare  the  first  elements  with  'equal',  delete  them  from  the 
ists  and  then  compare  the  rest  of  the  lists  with  'equal'.  This 
is  the  simplification: 


equal (x,.y)  =>  equal ( x[  1  ]  ,y[  1  ] )  and  equal ( rest  (  x) ,  rest (y) )  , 
if  x  and  y  are  non-null  lists. 


to 


Putting  our  results  together  allows  a  direct  translation 
lambda  calculus: 


th  e 
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equal  =>  X 


P f 

atom(x)  -> 
r  atom(y) 


->  x=y  I  false  ] 
atom(y)  ->  false 
null(x)  ->  null(y) 
null(y)  ->  false 

equal(x[ 1 ] ,y[ 1 J)  ->  equal ( rest ( x) , rest (7) ) 
false  1  1 


The  'atom'  tests  are  done  first  since  they  work  on  all  values 
(atoms  and  lists)  while  'null'  only  works  on  lists. 


3X3RCI33:  Write  out  the  reduction  of  equal(<5  <3  1 6 >  25>.  <5  <3 
1 S>  25  > ) . 

3X3RCI33:  Define  the  function  'member'  such  that  member (x, 7)  is 
true  if  and  only  if  x  is  an  element  of  the  list  y.  That  is 
member; C,  <A  3  C  D>)  =>  true,  but  member(C.  <A  <3  C>  D>)  => 
false.  Do  show  that  your  definition  works,  reduce  member(7,  <3  5 
7  9> )  . 
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S3:  Suppose  y  is 

a  1 

1st  of 

pairs 

.  i .  e 

i  t 

<<a^ 

b,  > 

1 

^  3-2  "fa  2 

>  • 

<an 

°n>> 

Define 

the  function  'assoc 

( x ,  y )  ' 

to 

be 

the 

firs 

x  =  a^ . 

For  instance, 

assoc(  'b ' ,  << ' a' 

1  > 

<  ’  b  ’  3> 

<  ’ 

/ 2  * 

5>> 

)  => 

assoc(  7,  <<1  0> 

<7  9 

>  <2  5> 

3»  ) 

=  > 

3X3RCI33 :  Suppose  x  and  7 

are  lis 

ts 

of 

the 

same 

foi 


wh  1  c  h 


7  i 


ist  or  narrs. 


For  instance, 


X  =  <X1  x9 

.7  =  <7j  7i 


xm> 

.  _  ^m> 

a  =  <<b1  c1Xb2  c2> 


<bn  cn» 


Define  ' pairlis(x ,7 , a) '  to  be  the  list  resulting  from  adding 
pairs  <x^  yp  to  the  front  of  a,  e.g.. 


«*1  7  ]  >  <xa  7a>  si>  <l3n  cn>> 

3X3RCIS3:  Write  the  list  processing  primitives  (first,  rest, 
cons,  atom,  null)  using  linked  lists  in  Pascal  or  some  other 
language  you  are  familiar  with. 


1.3.7  Syntactic  Sugar . 

With  the  list  processing  primitives  we  really  have  a  small, 
but  usable,  programming  language.  In  fact,  the  language  we  have 


*.+•  H-  O 


-  35  - 


is  very  similar  to  the  list  processing  language  LISP,  which  we 
will  be  discussing  later.  To  make  the  programming  language 
aspects  of  the  lambda  calculus  more  obvious  we  will  "sugar"  it 
with  an  Algol-style  syntax.  First,  we  will  replace  ’X'  with 
'proc'  (for  'procedure'),  we  will  write  the  bound  variables  in 
parentheses  separated  by  commas  (i.e.  'xy'  becomes  '(x.yV),  '{' 
and  ’!'  become  'begin'  and  'end',  ' [ '  and  ']'  become  'if  and 
' endif ' ,  '->'  becomes  'then'  and  ' | '  becomes  either  'elsif  or 
'else'.  When  we  make  these  substitutions  in  the  'equal'  function 
we  get: 


Equal  =>  proc ( x , y ) 
begin 

if  atom(x)  then 

if  atom(y)  then  x=y  else  false  endif 
elsif  atom(y)  then  false 
elsif  null(x)  then  null(y) 
elsif  null(y)  then  false 

elsif  equal ( x[ 1  ] ,  y[ 1 j )  then  equal (  rest(x),  rest(y)) 
else  false 
endif 
end 


These  conventions  are  summarized 

in  the  following  diagram 

Axy 

=  > 

nroc ( x ,y) 

{  ...  ! 

=  > 

begin  . . .  end 

r 

=  > 

1 1 

-> 

=  > 

then 

1 

=  > 

else  or  elsif 

] 

=  > 

endif 

We  will  use  the  acronym  'E1C' 

to 

refer  to  the  extended 

alculus ,  i.e.  to  the  cure  lambda  calculus  extended  by  the 
nteger,  Boolean  and  list  data  types  and  extended  by  the  syntac- 
ic  sugar  introduced  in  this  chapter. 


Approximate 
d if f erences 
chapter ) . 


quite  similar  to 
equivalences  are 
are  fairly  subtle 


the  programming  language  LISP, 
shown  in  the  following  chart  (the 
and  are  discussed  in  a  later 


k 
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oroaran  corresponding  to  our 


;aual '  function  i 


(equal  'lambda  (x  y) 
( cond 

((atom  x)  (cond 


(atom  7)  ( 
T  ”11) )  ) 


\  \ 

eq  x  7 . j 


((atom  7)  im, > 

((mull  x )  (null  7)) 

((null  7)  ;r;i) 

((equal  (car  x)  (car  7')  (equal  ' cir  x)  (car  7')  ' 

!  'i’-t  \  )  )  ) 


You  car.  now  see  that  languages  can  have  very  different  an 
ances  even  though  they  are  the  same  underneath.  Ye  will 
that  most  programming  languages  are  sugared  versions  of 
lambda  calculus. 


is  has  two  advantages.  First,  it  reduces  the  size  and  com 
y  of  each  expression  so  that  they  can  be  more  easily  as 
lated  by  the  eye.  Second,  by  using  the  same  variable  ’ u’  in  both 
daces  it  makes  it  more  obvious  that  it  is  the  same  identical 


Pi  CO 
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expression  in  both  places.  Now,  we  can  accomplish  the  same  thing 
in  the  lambda-calculus .  In  particular, 


ax+b 


reduces  to 


u:a 

/ax+b 

,  m+n-2 

\-y—  aJ 

1  * 

1.7.9  local  declarations  in  the--  lambda  calculus  The  "where" 
notation  will  be  defined  as  a  "syntactic  sugaring"  of  function 
application : 

2  where  v=x  =>  /  v  J  2 }  (  x ) 

For  instance,  an  expression  such  as  this  (which  is  taken  from  the 
interpreter  discussed  later): 

eval(  f[l][ 2],  append (  f[2],  conslx.O)1  )) 

could  now  be  written 

eval(  f[ll[2],  NewFnv  ) 

where  NevSnv  =  append(  f[2],  cons(x,<>)) 

By  analogy  with  functions  of  several  arguments,  it  is  possible  to 
allow  compound  "where”  declarations: 

3  where  v1 =x1  and  vP  =  xP  and  ••• 

=>  Vvfvp •  •  •  | BTTxi ,Xo , . .T^“ 


■1  ,  AP  t  •  •  -T 

For  instance,  the  expression  fragment 

elsif  e[l]  =  ' var '  then  a[e[2 ] ] [ e[3 ] ] 

can  be  more  readably  written 

el3if  e[l]  =  'var'  then  a[ep][vp] 
where  ep  =  e1  2 1 
and  vp  =  ef  7  J 

There  is  another  way  in  which  mathematicians  use  variable  names. 
If  a  mathematician  is  going  to  use  an  expression  in  a  number  of 
following  lines  then  he  will  often  give  it  a  name  with  a  phrase 


such  as  "Let  u  be 


ax+o 


defined  in  the  lambda-calculus: 


Inis  style  of  definition  is  easier 
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let  v=x  _in  3  =>  >vfz!:’x) 

or  in  general 

let  v^=x<  and  v0=x?  and  •••  in  Z 
=  >  >V1  v?  •  •  •  (Z’  Tx.,  7x2 - - 

Tn e trier  'let'  or  'where'  is  used  is  largely  a  natter  of  taste  an 
style.  In  general,  'where'  is  appropriate  vhen  ' Z '  is  one  lin 
or  less  and  'lot'  is  appropriate  when  'Z'  is  more  than  one  line. 
As  an  example  of  'let',  the  expression  fragment 

elsif  e:  1 ]  =  ' call '  then 

apply(  evai'  e'_2],  a),  evlis(  rest  ( rest  ( e) }  ,  a)  ) 

can  be  written 

elsif  e[l]  =  'call'  then 
let  closure  =  eval(ei2],a) 
and  actuals  =  eval(  rest ( rest ( e) ) ,  a)  in 
apply(  closure,  actuals  ) 

Zhe  use  of  names  such  as  'closure'  and  'actuals'  makes  the  pro¬ 
gram  more  readable,  albeit,  more  verbose. 

1.3.10  terminology  It  will  be  recalled  that  in  the  abstraction 
'  A  x  { Z  ?  '  the  scope  of  ’x’  was  defined  to  be  ’Z’.  B.y  analogy,  the 
scope  of  the  variables  defined  by  a  ’let’  or  a  'where'  is  defined 
to  be  the  body  of  the  corresponding  abstraction.  For  instance, 
in  the  previous  example,  the  scope  of  'closure'  and  'actuals'  is 
the  following  line.  Zo  put  it  another  way.  the  scope  of  a  vari¬ 
able  is  the  region  of  an  expression  over  which  it  has  meaning. 
Zhis  is  shown  in  the  following  diagrams: 

Av>Z! 

— scope  of  'v' 


Z  where  v=x 


Consider  the  following  'let'  or  'where'  expressions: 

Z  where  v^  =xi  and  ^2  =  xo  and  • • ■ 
let  v-)  =Xi  and  v?  =  x?  and  •  •  •  in  Z 


(D  ^ 
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The  ' v;=x^'  parts  of  these  are  called  def initions ,  declarations 
or  bindings  (because  they  bind  a  bound  variable  to  its  value) . 
The  'let'  and  'where'  constructs  themselves  are  called  blocks 
(particularly  in  languages  that  delimit  them  with  begin-end 
pairs).  These  constructs  occur  in  most  languages  although  in  a 
variety  of  forms.  For  instance,  the  Algol-68  block 


begin  i=3;  j=m+1 ; 

i/3 

end 

means  the  same  as  the  lambda-calculus  block 

let  i  =  3  and  j=m+i 
in  i/j 

In  languages  that  use  begin-end  pairs  to  delimit  blocks,  like 
Algol-63,  the  declarations  ( ’ i =3 ;  j=m+1 '  in  this  case)  are  col¬ 
lectively  known  as  the  head  of  the  block,  and  the  rest  of  it  is 
known  as  the  body  of  the  block.  Thu3 , 

.bindings  (definitions,  declarations') 


'  ^  . 

begin  i=3;  j=m+1 ;  i/j  end 

V  ‘  X 

'block  block  head 


head  block  body 


A  set  of  Pascal  declarations  such  as 

function  g(y: integer) :  integer; 
const  i=3; 

function  f(x: integer) :  integer; 

begin  f  :=  x*i+1  end; 
begin  g  :=  f(y)+1  end; 
begin  . . .  end 

means  the  same  as  the  lambda  expression 

let  g  =  proc(y)  begin 
let  i=3  in 

let  f  =  proc(x)  begin  x*i+1  end  in 
f(.y)+1  end 

in  ... 

If  course,  it  is  necessary  to  specify  types  in  Pascal  declara¬ 
tions,  but  not  in  lambda-calculus  bindings. 

A 3  a  final  example  of  blocks  in  the  lambda-calculus,  con¬ 
sider  the  lambda  expression 
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let  =  e,  and  '^2  =  s2  ^n,  ex  | 

scope  of  both  v1  and  v0S 

The  second  of  these,  which  is  called  a  comapour.d  declaration .  is 
such  sore  than  merely  a  shorthand  form  of  the  first.  Observe 
that  in  the  first  expression  e?  is  within  the  scope  of  v,  . 
whereas  in  the  second  expression  the  scope  of  both  v1  and  v9  is 
just  ej .  7or  instance,  while 

let  i=3  in  let  x=A[i]  in  B 

has  the  same  effect  as 

let  x=a[3]  in  B 

the  expression 

let  i=3  and  x=a[i]  in  B 

is  illegal  (i.e.  doesn't  make  any  sense),  unless,  of  course,  'i' 
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is  bound 
clearly  by 
notation . 


in  some  surrounding  scope, 
translating  the  two  expressions 
The  first  becomes: 


This 

back 


can  be  seen  more 
to  pure  lambda 


Ail  Ax|B}(  A [ i ]  )  }  (3) 


bound  occurence  of  ' i 


scooe  o 


■P  ’  Y  ’ 


scope  of 


which  is  correct,  and  the  second  becomes: 

>ix{ 3} (  3,  A[i]  ) 

1 _ I 

scooe  of  ’  i  *  and  'x'  <~uinbound  occurence  of  ' 


which  is  not.  The  most  important  use  of  compound  declarations  13 
in  connection  with  recursive  declarations,  discussed  next. 


1.3.12  recursive  declarations  Consider  a  ieclaration  such  as 

let  fac  =  proc(n){  [n=0  ->  1  !  n*fac(n-1 ) ]  } 

in  B 
1 _ 1 

^scope  of  'fac' 

Thi3  is  illegal,  as  we  can  see  by  putting  it  in  pure  lambda  nota¬ 
tion: 

>  1  I  n*fac ( n-1 ) ]  }  ; 

unbound  occurence  of  'fac' 

The  recursive  occurence  of  'fac'  is  unbound.  This  is  because  the 
value  on  the  right  of  a  binding  is  evaluated  in  the  surrounding 
environment.  This  is  clearly  an  unsatisfactory  situation. 
Although  there  are  ways  of  handling  recursive  definitions  in  a 
purely  applicative  way,  they  involve  complicated  mathematics  and 
so  will  not  be  discussed  here.  Instead,  the  technique  to  be  used 
will  require  some  of  the  imperative  facilities  discussed  in  the 
next  chapter.  Although  the  actual  technique  to  be  used  will  not 
be  described  until  the  next  chapter,  recursive  definitions  will 
be  U3ed  in  this  chapter. 

A  declaration  of  the  form 


Afac  |  3  |  (  An|  1"  n=0  - 

i _ i 

score  of  'fac' 


O'  cl- 
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let  rec  v=e  in  B 

l - 1 

scope  of  ’v’ 

is  called  a  recursive  declaration  (or  definition  or 
because  the  scope  of  ’v1  includes  'e'.  Therefore  ’e’ 
use  of  ’v’.  Similarly,  compound  recursive  declarations 
defined  so  that  in 

let  rec  v^  =e^  > 
and  rec  v?feo 
and  ...  in ' 3~  ! 

^~scope  of  v. ,  v2 ,  • • • 

he  scopes  of  v1 ,  v? ,  ...  include  e. ,  e7,  ...  .  This  al] 
efinition  of  mutually  recursive  functions,  for  instance: 

let  rec  Bval  =  proc(e,a)f  ...  apply( . . . )  ...  } 
and  rec  Apply  =  proc(f.x){  ...  eval(...)  ...  } 
in  ... 


b inding) 
can  make 
will  be 


ows  the 
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Chapter  4 


I . 4  Implementing  The  Lambda  Calcul us 

1 . 4 . 1  goals  defined . 

You  have  Probably  found  reducing  lambda  calculus  expressions 
to  be  a  tedious  and  error-prone  process.  These  character istics , 
plus  the  fact  that  reduction  is  a  mechanical  procedure,  makes  the 
computer  the  ideal  tool  for  doing  these  reductions.  There  are 
several  reasons  for  this,  when  people  work  for  a  long  ti^e  at  a 
mechanical  cask,  they  become  tired  and  begin  to  make  miscakes. 
Computers  aren't  like  chat:  once  programmed  correctly  they  will 
perform  a  cask  wichouc  facigue.  Another  advancage  of  using  com- 
oucers  to  do  reductions  is  that  they  can  do  then  so  fast.  The 
mechanical,  symbolic  processes  of  a  calculus  are  exactly  whac 
computers  handle  best,  since  a  computer  is  just  a  very  fast  sym¬ 
bol  manipulator. 

Whv  are  we  so  concerned  about  reducing  lambda  expressions, 
anyway?  As  you've  seen  in  the  Previous  chapter,  languages  with 
very  different  appearances  are  often  just  "sugared"  versions  of 
the  lambda  calculus.  You've  also  been  told  (and  you  will  see  ic 
in  Parc  II)  that  most  common  programming  languages  are,  under¬ 
neath,  just  the  lambda  calculus.  Therefore,  it  you  study  how  to 
implement  the  lambda  calculus,  you  will  be  learning  how  to  imple¬ 
ment  most  of  the  common  programming  languages.  The  advantage  of 
using  the  lambda  calculus,  as  opposed  to  Pascal  or  Ada,  for 
instance,  is  that  the  lambda  calculus  is  so  simple.  The  imple¬ 
mentation  techniques  are  much  easier  to  understand  in  the  clear 
and  uncluttered  context  of  the  lambda  calculus.  Once  understood, 
they  are  easy  to  extend  or  modify  so  that  they  accomodate  the 
complexities  of  "real"  languages. 

1.4.2  mechanical  reduction 

Having  established  that  imolemenation  of  the  lambda  calculus 
is  important,  we  can  proceed  to  study  how  we  might  go  about  it. 
The  obvious  approach  is  to  write  a  program  that  duplicates  our 
hand  reduction  procedures.  This  is  easier  said  than  done,  how¬ 
ever  . 

Let's  investigate  how  we  miqht  go  about  automating  the 
reduction  process.  When  we  reduce  a  lambda  expression  using  the 
Standard  Reduction  Order,  we  do  it  bv  applying  the  substitution 
rule  over  and  over,  until  we  are  forced  to  stop  by  an  immanent 
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collision  or  variables.  We  chen  use  the  renaming  rule  to  change 
the  oftendinq  bound  variable  to  one  that  won't  cause  a  collision, 
and  continue  with  our  substitutions.  Fxceot  on  verv  Comdex 
lambda  expressions  it  is  generally  easy  to  see  it  there  will  be  a 
collision  or  variables.  This  sort  or  oattern  recognition  orocess 
is  the  sort  or  thing  that  is  very  easy  tor  people  and  very  hard 
tor  computers.  This  is  because  we  can  see  the  collision  ac  a 
glance,  while  the  computer  must  do  the  check  with  an  exhaustive 
search.  That  is,  in  order  to  determine  if  it  is  legal  to  substi¬ 
tute  an  actual  oarameter  for  a  particular  (free)  occurence  of  a 
variable,  it  is  first  necessary  to  compute  a  list  of  the  free 
variables  in  the  actual  parameter.  Doing  this  requires  scanning 
the  expression  and  noting  all  the  binding  sites  and  their  scopes. 
It  is  then  necessary  to  compute  all  the  variables  whose  scopes 
contain  the  prospective  substitution  site,  and  to  determine  if 
uny  of  these  variables  are  the  same  as  free  variables  of  the 
actual  parameter.  This  is  a  expensive  check  to  perform  and 
intricate  and  tricky  to  program. 

Another  reason  to  avoid  a  mechanical  implementation  of  the 
reduction  procedure  is  that  it  would  be  slow.  As  you've  probably 
observed  in  your  own  reductions,  this  process  involves  a  lot  of 
recooying  of  the  formulas.  This  is  something  that  most  computers 
don't  do  well.  For  these  reasons  we  will  investigate  an  imple¬ 
mentation  that  involves  neither  textual  substitution  nor  a  com¬ 
plicated  collision-of-var iables  test. 

1.4.3  context 

Let's  take  another  look  at  the  way  people  use  variables. 
Suppose  a  mathematician  reads  a  phrase  such  as,  "Let  0  -  2Hft." 
what  happens  when  he  later  reads  a  formula  such  as 
"2sin  0  cos  6"?  Does  he  mentally  transform  this  into 

2sin(2flft)  cos(2'tft) 

by  oerformming  the  substitutions?  Of  course  not.  Having  been 
told  "Let  0  =  2ttft",  he  remembers  this  fact  and  associates  0  with 
2flft.  we  say  that  he  has  bound  0  to  2flft.  when  he  reads  the 
formula  "2sin  0  cos  0"  he  interprets  it  contextually,  i.e.,  in 
the  context  of  the  relevent  meanings  of  2,  sin,  cos  and  0.  It  is 
not  necessary  for  him  to  do  a  textual  substitution. 

You  will  remember  that  the  reason  tor  the  collision-of- 
variables  restriction  on  the  substitution  rule  was  to  prevent 
altering  the  meaning  of  an  expression  by  changing  the  context  of 
its  interpretation.  In  this  case  the  context  is  just  a  set  of 
bindings ,  i.e.,  associations  between  variables  and  their  values. 
In  the  next  section  you  will  see  how  to  keep  track  of  the  context 
of  a  formula  in  such  a  way  that  it  can  be  evaluated  without  the 
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use  or  substitution,  renaminq  or  collision  tests. 
1.4.4  hand  evaluation 


In  this  section  we  will  study  the  use  or  the  context  or 
environment  of  a  formula  ■»  i.e.,  the  set  ot  bindings  that  a ive 
that  formula  its  meaning.  These  will  be  reoresented  by  diagrams 
of  the  form: 


0 

2*ft 

2sin 

0  cos  0 

This  expreses  the  fact  that  the  context  of  the  formula 
'  2sin  0  cos  0'  is  the  binding  ot  0  to  2l*ft. 

As  our  first  example,  let's  consider  the  evaluation  of  'x+1' 
in  a  context  in  which  x  is  bound  to  2,  i.e.. 


x  1 

2 

n 

x+1 

Since  this  is  the  context  of  the  entire  formula,  it  is  also  the 
context  in  which  each  of  its  subformulas  must  be  interpreted. 
Hence,  this  can  be  reduced  to 


+ 


Now,  the  interpretation  of  x  in  the  context  x=2  is  just  2,  so  we 
have 


2  + 


and  the  interpretation  of  i  in  any  context  is  1,  so 
2+1 


or  3.  Similarly,  we  can  evaluate  x*y  in  the  context  v=  3 ,  x=2. 


3 

Y_ 

UT 

V 

3 

X 

2 

*y 

=  >  X 

X 

X 

y 

Jj 

Next,  we'll  take  a  more  complicated  example,  the  evaluation  ot 
*>y { x * y } (x+1 ) ’  in  the  environment  x=2: 


x*y} (x+1) 


hetore  we  can  bind  y  to  x+i  we  have  to  know  the  value  ot  x+i  (in 
context,  ot  course).  Hence,  we  will  separate  the  two  oarts  ot 
the  application: 


Notice  that  we  have  kept  the  formula  >y{x'vl  in  context  -  other¬ 
wise  it  would  lose  its  meaning.  Continuing  our  evaluation,  we 
previously  saw  that  x+i  in  the  context  x=2  evaluates  to  3,  so  we 
have: 


what  is  the  effect  of  >y{x*y}(3)?  It  is  to  add  the  binding  y=3 
to  the  context  of  interpretation: 


we  have  previously  seen  that  this  reduces  to  h . 

We  will  expand  on  the  previous  example  a  little.  In  that 
example  we  applied  to  the  argument  3  the  function  >v(x‘y}  in  the 
context  x=2,  i.e.,  the  funnction  represented  by 


Next  we  will  consider  the  evaluation  of  f ( 3 )  in  a  context  that 
binds  f  to  the  above  function.  The  result,  of  course,  should  be 
the  same.  We  start  with 


We  must  evaluate  the  operator  and  operand  separately: 


Constants  are  independent  of  the  context,  so  the  operand's  value 
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is  3.  The  ooerator  is  a  variable,  f,  which  must  be  interpreted 
in  the  context.  When  when  we  substitute  this  definition  we  qet: 


(3) 

which  we  have  already  seen  is  5.  Motice  that  we  have  always 
oreserved  the  meaning  of  >y{x*v}  by  bringing  the  context  along 
with  it.  We  are  now  at  the  point  where  we  can  formally  state  our 
evaluation  rules. 

1.4.5  constants 

Since  the  value  of  a  constant  does  not  deoend  on  its  con¬ 
text,  we  evaluate  it  bv  eliminating  the  context. 


=  >  k 

tor  k  a  constant . 

1.4.5  variables 

In  contrast  to  constants,  the  value  of  a  variable  depends 
entirely  on  the  context.  We  find  the  value  of  a  variable  by 
looking  it  up  in  the  list  of  bindings  in  the  contour  (bv  conven¬ 
tion,  we  take  the  first  occurence  of  the  variable  in  that  list). 
The  rule  is: 


=  >  x 


where  v  is  a  variable. 

If  x  is  not  bound  in  this  context,  then  it  is  free  (i.e.,  so  far 
as  we  know  it  has  no  value) . 

1.4.7  abstractions 

An  abstraction  often  will  have  free  variables  that  are 
defined  in  its  context.  If  this  context  is  not  preserved  then 
the  abstraction  will  change  its  meaning.  Therefore,  we  will 
leave  an  abstraction  unevaluated  until  it  is  ready  to  be  applied 
to  some  arguments,  we  show  this  delay  of  evaluation: 


i 
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o  1 

o 

AxUl 

=> 

/x  { R } 

(no  change) 


1.4.9  applications 


Consider  an  application  such  as  'f(x+l)‘.  Standard  Reduc¬ 
tion  Order  says  that  in  order  to  determine  its  value  it  is  first 
necessary  to  determine  the  value  of  its  operand,  'x+i',  and  its 
operator,  'f'.  Of  course  the  value  of  each  of  these  is  found  by 
interpreting  it  in  the  context  of  the  entire  application: 


El 

0  ( 

o  ! 

L  *(e)| 

=  > 

f 

( 

I  e 

Of  course,  there  is  more  to  the  evaluation  of  applications  than 
this.  If  the  application  is  to  make  sense  then  the  evaluation  of 
the  operator  must  result  in  an  abstraction  (with  its  context) . 
That  is,  we  will  get  a  result  like: 


>xfQ}  !  (A) 


Vow,  this  means  that  C  is  the  context  of  the  abstraction  /x{E}. 
The  application  above  is  evaluated  by  adding  the  binding  x=A  to 
the  context  C,  and  then  using  this  as  the  context  in  which  to 
interpret  1.  Summarizing,  the  rule  is: 


— l  | 

( |(A)  => 


I. 4. 9  Primitive  applications 


We  have  air eadv  seen  several  examples 
primitive  applications,  such  as  'x+i' 
these  it  was  first  necessary  to  evaluate 
primitive.  This  leads  to  the  general  rule 


of  the  evaluation  ofN 
and  ' x *v ' .  In  each  of 
the  operands  of  the 


r _ 1 

c 

c 

o (  xi ,  . . . ,  xn) 

=  >  p( 

_ 

xi 

t  •  •  •  r 

xn 

1.4.10  conditionals 


Recall  that  we  specified  a  deviation  from  Standard  Reduction 
Order  for  conditionals.  We  said  the’  ve  would  first  reduce  the 
condition  and  then,  depending  on  whether  the  result  was  'true'  or 
'false',  reduce  either  the  true  branch  or  the  false  branch.  This 
avoids  errors  in  situations  where  the  other  branch  is  not 
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reducible.  Reducing  the  condition  is  accomplished  bv  the  rule: 


=  > 


When  the  condition  has  evaluated  to  'true'  or  'false'  the  follow¬ 
ing  rules  interpret  in  context  the  corresponding  branch. 


=  > 


=  > 

1.4.11  examole  of  hand  evaluation 

As  an  example  of  these  procedures  we  will  evaluate 
let  i=3  in 

let  f  =  proc(x)f  x‘i  }  in 
let  i  =  2  in 
f  (i) 

which  we  saw  in  Chapter  3.  The  crucial  aspect  of  this  example  is 
that  the  context  of  oroc{x){x'il  is  i=3 .  We  can  see  that  this 
context  is  preserved  in  the  following  figure.  In  this  examole  we 
first  eliminate  syntactic  sugar  and  write  the  above  formula: 

*i{  >f{  *i{  f  ( i )  }  ( 2 )  >(>x{x*U  )  }  ( 3 ) 

1.4.12  representation  defined 

We  will  next  write  an  interpreter  for  ELC  (the  extended 
lambda  calculus)  in  ELC.  Since  we  will  be  using  ELC,  and  the 
only  primitives  we  have  in  ELC  are  for  manipulatino  lists,  we 
will  have  to  encode  lambda  expressions  as  lists  so  that  thev  can 
be  manipulated.  This  is  the  representation  we  will  use: 


FORM  EXAMPLE  REPRESENTATION 

constants  2  Cconst'  2> 

'string'  C'const'  ' string' > 

<5  9  1S>  < ' const '  <5  8  IS>> 

variables  x  <’var'  'x’> 

abstractions  >xy{E}  Clambda'  <’x'  'y’>  S> 

applications  F  (A ,  B)  <’call'  E  <A  B>> 

prim,  applies.  cons(A,B)  <’prim'  'cons'  <A  B>> 

conditionals  f  c  — >  t  i  f  1  < '  i f  '  c  t  f> 


figure  i.  Example  of  Hand  Evaluation 

It  is  necessary  to  append  the  "taq  word”  'const'  to  the  beginning 
of  constants  to  prevent  contusion,  for  instance,  between  the 
lists  representing  variables  and  constant  lists  that  haooen  to 
begin  with  the  string  'var'. 


We  will  look  at  several  examples  of  lists  that  represent 
lambda  expressions.  The  expression 
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t (1 . 2) 


is  represented  bv  the  list: 

<’call'  <’var’  ' t  ">  «' const '  1>  <'const'  2>> > 
The  primitive  application 


sons  fy , O ) 


is  represented  by 

<'orin'  'cons'  « 1 va r '  '  v‘>  <' const'  <>>  » 

For  a  more  complicated  example,  consider: 

Axv(  cons  {  x,  const  y,  <>  ))  } 

This  is  represented  bv 

< ' lambda '  <'x’  '  y '  > 

<’prim'  'cons'  «'var'  '  x  ’  > 

<’orim'  'cons'  <<’var'  v’> 

<  '  const '  <>>  > > >  » 


1.4.13  r ield  accessing  functions 

Suppose  L  is  a  list  representing  an  abstraction,  e.g.. 
<'lambda'  <’x'  '  v  ">  C’var'  'x'^ 

It  we  wish  to  extract  the  bound  variables  trom  L,  we  can  do  this 
by  L [ 2 1 : 

L r  2 1  =>  < ' x '  'y ’ > 

Similarly,  the  body  at  the  abstraction  can  be  extracted  by  LT31: 

L [ 3 1  =>  < ' va  r '  ’x'> 

Soth  of  these  operations  will  be  more  readable  it  we  detine  the 
field  accessing  tunctions  'bvs''  and  ''body'"  to  get  the  bound  vari¬ 
ables  and  body,  respectively,  of  an  abstraction: 

let  bvs  *  oroc(x){  x  T  2 1  1 

and  body  =  oroc(x)f  x  f  3 1  }  in  ... 


Then  we  can  write 


hvs  ( L)  =■>  <  '  x  '  ’  v  '  > 

bo^vfL'  =>  <’var'  ’x'o 

It  will  also  be  usetui  to  have  a  tunction  ’  i s- lambda '  to  tell  as 
it  a  list  reoresents  an  a  b  s  t-  r  action: 

let  is-lambda  =  orocfxW  x  f 1 1  =  'lambda*  }  in  ... 

This  function  determines  it  a  list  reoresents  an  abstraction  bv 
checkinq  it  its  'taq  word"  is  'lambda'.  ror  instance. 

i s-» lambda  (L)  ->  true 

is-lambda(  < 'const'  2>  )  =>  talse 

Ot  course,  we  will  want  functions  like  'hodv'  and  'is-lambda'  tor 
each  ot  the  lists  which  reoresent  a  tyoe  ot  lambda  expression. 
Rather  than  detine  each  seoaratelv  like  we  did  above,  we  will  use 
the  abbreviation 

structure  lambda:  (bvs,  body ) 

to  mean  that  lists  whose  tirst  element  is  'lambda'  will  have  two 
more  elements,  selected  by  the  tunctions  'bvs'  and  'body'.  This 
is  called  a  structure  definition  and  is  equivalent  to  the 
declaration: 

let  is-lambda  =  oroc(x)f  x r 1 ]=' lambda '  } 
and  bvs  3  oroc(x)f  x(2T  ? 
and  body  =  oroc(x){  xf31  } 
in  ... 

The  structure  declarations  tor  the  lists  that  reoresent  lambda 
expressions  are  qiven  in  the  t'ollowinq  figure.  The  definition  ot 
these  tield  accessinq  tunctions  will  make  our  interpreter  much 
more  readable. 

structure  const:  (constval) 
structure  var:  (id) 
structure  lambda:  (bvs,  body) 
structure  call:  (rator,  rands) 
structure  orim:  (rator,  rands) 
structure  it:  (cond,  t-branch,  f-branch) 

rigure  2.  Lists  beoresentinq  Lambda  Expressions 

1.4.14  association  lists . 

So  that  environments  (contexts)  can  he  manipulated  bv  the 
primitives  with  which  we  have  equiooed  the  lambda  calculus,  we 
will  detine  a  reoresentation ,  called  an  association  list  (or  a- 
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1  i  s  t  >  .  tor  environments.  a>n  association  list  is  just  a  list 
wherein  each  element  ot  the  list  is  a  pair  containing  the  name  ot 
a  variable  and  its  value.  por  instance,  an  association  list 
reoresenting  an  environment  in  which  x=2,  v* ' Center ev ’  and  z=<0  i 
2 2  is: 

<  <’x’  22  < 1 y '  'Monterev'2  <’z*  <0  1  2>>  > 

'•>e  will  detine  several  orimitive  functions  on  association  lists. 
The  function  'assoc'  is  defined  so  that  * assoc ) x , a) '  is  the 
result  ot  looking  uo  that  variable  name  x  in  the  association  list 
a . 

let  rec  assoc  =  oroc)x,a>  begin 

it  equal (  x,  a r 1 ] f 1 1 )  then  a  [11)21 
else  assoc)  x,  rest(a))  endit  end. 

por  instance,  it  L  is  the  a-list 

<  <'x’  2>  < ' y '  ' ^onterev ' 2  <’z’  <b  1  22>  2 


then 


assoc)  'y'.  Cl  =>  ’Monterey'. 

The  function  'oairlis'  is  a  little  more  complicated;  it  is  used 
tor  binding  variables  to  values  and  ad^ino  them  to  a-.  * i a  t i  on 
list.  That  is.  if  x  is  a  list  ot  variable  n»->es .  v  is  a  list  ot 
values  and  a  is  an  association  list,  then  ' oairlis (x.y, a) '  is  an 
association  list  in  which  each  element  ot  x  is  oaired  with  the 
corresnondinq  element  of  y  and  aDoended  to  the  front  or  a.  c'ot 
instance, 

pairlis)  <‘w'  'cost'>,  <5  252,  L  ) 

=2  <<’w'  52  < ’cost1  25>  <’x’  22  < ' y '  ' Monter ev ' 2  <'z'  <o  i  22>>. 

To  see  how  this  can  be  done,  notice  that  if  'a'  is  an  a-list,  and 
<xi  yi>  is  a  oair  reoresenting  a  binding,  then 

cons)  <xi  vi>, 

will  add  this  oair  to  'a'.  The  resulting  definition  of  ‘oairlis’ 
is: 

let  rec  oairlis  =  proc)x,y.a)  begin 
it  null(xl  then  a 
else  cons)  oair)  x[ll,  y f i 1  ), 

pairlis)  rest(x),  rest(y).  a)  )  endit  end 
where  Pair  s  proc(x,y){  cons)  x,  cons)  y,  <2  ))  1. 


I  .  4  .  i S  closures 

We  have  oreviously  seen  that  it  is  necessary  to  keen  an 
abstraction ' s  context  with  that  abstraction  in  order  to  oreserve 
its  meaning.  We  have  symbolized  this  with  diagrams  like: 

1 — ti - 

i  x  i  3 

I  X'/fx+y} 

We  will  now  investigate  in  more  detail  the  nature  of  this  con¬ 
struct  . 

A  formula  is  called  closed  if  it  has  no  free  variables,  for 
instance , 

X* {  >y { x+y}  } ( 3 ) 

Closed  formulas  are  imDortant  because  their  internr station  is 
completely  independent  of  context.  A  formula  is  called  ooen  it 
it  has  one  or  more  free  /acii’oles.  Hence,  open  formulas  are 
dependent  on  their  context  for  their  interpretation.  This  for¬ 
mula  is  open: 

Xy { x+y } 

An  open  formula  can  be  closed  by  oroviding  bindings  for  its  free 
variables.  For  instance,  the  above  open  formula  can  be  closed  by 
binding  x  to  3: 

let  x=3  in  >y { x+y} 
o  r 


X<  {  Xy  {x+y}  }  (3) 


This  is  called  the  closure  of  the  formula  Xv{x+y}.  More  gen¬ 
erally,  a  closure  is  a  formula  together  with  bindinos  for  all  of 
its  free  variables.  This  is  just  the  construct  we  have  illus¬ 
trated  by 


x  |  .3 

V 

-< 

x+y} 

Our  next  task  will  be  to  determine  how  we  can  Implement  closures 
using  lists.  The  key  is  our  diagram;  a  closure  has  two  parts: 
an  abstraction  and  its  context.  These  parts  are  traditionally 
called  the  ijo  and  ep,  which  stand  for  instruction  part  and 
envi r onmen t  part,  respectively.  We  will  reoresent  a  closure  by  a 
structure  with  two  fields  called  'ip'  and  'ep'.  The  iD  will  be  a 
list  that  reoresents  an  abstraction  and  the  ep  will  be  an  a-list 
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representing  a  context.  This  is  summarized  by 

structure  closure:  (in,  eo) 

The  function  tor  constructing  closures  is  defined: 

let  closure  =  proc(ip,ep){ 

const  'closure',  oairt  ip,  eo  ))  } 

Thus,  we  can  make  a  closure  from  the  abstraction  f  and  the 
environment  e  by  closur e  (  f , e) : 

closure(t,e)  =>  <'closure'  f  e> 


We  can  test  if  something  is  a  closure  bv  is-closure  (c)  and 
extract  its  oarts  by  iro(c)  and  ep(c).  The  closure  data  type  is 
described  in  the  following  figure. 


io(  closure(f,e)  )  =  f 

ep(  closure(f.e)  )  =  e 

closure(  ip(c),  en(c)  )  = 

c 

is-closure(  closure(f,e)  ) 

=  true 

where  is-lambda ( f ) 

and  e  is  an  a^list 

and  is-closure (c) 

Figure  3.  The  Closure  Data 

Type 

1.4.15  mechanical  evaluation. 


We  will  define  a  function  'eval'  such  that  if  'e'  is  a  list 
representing  a  lambda  expression  and  'a'  is  an  association  list 
representing  an  environment,  then  'eval(e,a)'  is  the  result  of 
evaluating  that  lambda  expression  in  that  environment.  Thus, 
'eval(e,a)'  corresponds  to 


JL_J 

e 


The  structure  of  our  interpreter  will  be  a  large  conditional  so 
that  we  can  handle  lambda  expressions  case  by  case.  In  skeleton 
form  it  is: 


A 
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let  rsc  Dval  =  3toc(e,a) 
begin 

it  is-const(e)  then  ... 

elsif  is-var  (e)  then  ... 

eisit  is-lambda (e)  then  ... 

eisit  is-call(e)  then  ... 

eisit  is-Drim(e)  then  ... 

eisit  is-if(e)  then  ... 

end  i  t 
end 
in  ... 

We  will  consider  each  ot  these  cases  in  turn.  In  discussing 

them,  it  will  be  helpful  it  vou  reter  back  to  the  tield  names 
defined  in  figure  2, 

The  simolest  case,  as  we  have  already  seen,  is  constants, 

because  they  do  not  deoend  on  the  context  for  their  interoreta- 

tion.  In  this  case  we  just  extract  the  constant  value  from  the 
list  and  return  it: 

if  is-const(e)  then  const-val(e) 

The  next  simpler  case  is  variables.  The  result  of  evaluating 

<’var'  x>  is  just  the  result  of  looking  up  x  in  the  current 
environment  (which  is  the  a-list  bound  to  'a'): 

elsif  is-var(e)  then  assoc(  id(e),  a) 

^s  discussed  in  the  previous  sections,  the  rule  for  abstractions 
will  form  a  closure  by  combining  the  abstraction  and  its  environ¬ 
ment  of  definition  (context).  This  is  accomplished  bv: 

elsif  is-lambda(e)  then  closure(e,a) 

When  this  closure  is  apnlied  to  its  ooerands  by  a  application, 
the  'apply'  function  will  extract  the  environment  on  definition 
(ep)  from  the  closure  and  use  it  as  the  basis  for  constructing 
the  environment  of  evaluation  for  the  bodv  of  the  abstraction 
(io)  . 

Mext  we  will  consider  the  case  of  Primitive  applications. 
If  e  is  a  Primitive  application  then  rator(e)  is  its  operator, 
which  is  a  string  such  as  'first'  or  'cons',  and  rands (e)  is  a 
list  of  its  ooerands.  In  our  hand  evaluation  Procedure,  we  first 
interpreted  the  operands  in  context  and  then  performed  the  primi¬ 
tive  operation.  Here  we  will  use  an  auxilliary  tunction  'evlis' 
to  evaluate  the  ooerands  and  an  auxilliary  function  'apoly-orim' 
to  perform  the  operation: 
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elsif  is-orim(e)  then  apolv-prim(  rator(e),  actuals) 
where  actuals  =  evlis(  rands(e),  a) 


Flvlis  is  a  simple  recursive  procedure  that  evaluates  each  element 
or  its  argument  list  and  returns  a  list  of  the  results: 


let  rec  evlis  =  oroc(L,a)  begin 
if  null(L)  then  <> 

else  cons {  eval (  Mil,  a),  evlis(  rest(L),  a))  endif  end 


The  definition  of  'apoly-orim'  is  simply  a  conditional  for  han¬ 
dling  each  of  the  primitive  operations: 


let  apoly-prim  = 
if  f = ' first' 
elsif  f='rest' 
els  if  £=’ cons' 
elsif  f='atom' 
elsif  fa 'null' 
end i f  end  in  . . 


proc(r,x)  begin 
then  f i r  st  ( x  ( 11 ) 
then  rest (x [ 11 ) 
then  cons  (  x [1 ]  , 
then  atom  (x  Til ) 
then  null (x[ 11 ) 


x  r  21 ) 


Of  course,  if  we  want  additional  primitive  operations,  we  can 
just  add  clauses  for  handling  them  to  the  definition  of  'aoplv- 
prim'. 


The  application  of  non-orimitve  operations  is  a  similar  pro¬ 
cess.  The  operands  must  be  evaluated  using  'evlis',  as  was  done 
for  primitive  applications.  Since  the  operator  is  also  a  for¬ 
mula,  it  also  must  be  evaluated  in  context.  This  evaluation  must 
yield  a  closure.  The  closure  is  then  applied  to  the  actual 
parameters.  That  is: 

elsif  is-cali(e)  then  apply(  closure,  actuals) 
where  closure  =  eval(  rator(e),  a) 
and  actuals  =  evlis(  rands(e),  a) 

Next,  we  must  consider  what  'apply'  has  to  do  to  complete  the 
function  call.  In  our  hand  evaluation  procedure  we  paired  the 
bound  variables  with  the  corresponding  actual  parameters  and 
added  these  bindings  to  the  context  of  the  abstraction.  This  new 
context  was  use<  as  the  environment  for  evaluating  the  body  of 
the  abstraction.  We  will  do  the  same  here. 

If  b  is  the  list  of  bound  variables,  x  is  the  list  of  actual 
parameters  and  c  is  the  context  of  the  abstraction,  then 
pairlis (b,x,c)  is  the  environment  in  which  to  evaluate  the  body 
of  the  abstraction.  The  'applv'  function  that  accomplishes  this 
is : 
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let  rec  apDly  =  proc(  closure,  actuals)  begin 
let  abs  =  io(closure)  in 

let  env  =  pairlis(  bvs(abs),  actuals,  ep(closure)  )  in 
eval (  body(abs),  env  )  end 

The  only  case  left  to  be  analyzed  is  the  conditional.  In  our 
hand  evaluation  orocedure  we  interpreted  the  condition  in  context 
to  get  a  truth  value.  We  then  used  this  value  to  determine 
whether  to  evaluate  the  true  branch  or  the  false  branch  of  the 
conditional.  This  is  exactly  what  needs  to  be  done  in  'eval': 

elsif  is-if(e)  then 
i f  eval  (  cond  (e)  ,  a) 

then  evai(  t-branch(e),  a) 

else  eval  (  f-*branch  (e)  ,  a)  endif 

This  completes  the  definition  of  'eval';  the  complete  interpreter 
is  shown  in  the  following  figure. 


let  rec  Eval  =  proc(e,a)  begin 

it  is-*const(e)  then  const-val  (e) 
elsif  is-var(e)  then  assocl  id(e),  a) 
elsif  is-lambda(e)  then  closure(  e,  a) 

elsif  is-prim(e)  then  aDplv'prim(  rator(e),  actuals) 
where  actuals  =  evlis(  rands (e),  a) 
elsif  is-call(e)  then  apply (  closure,  actuals) 
where  closure  =  eval(  rator(e),  a) 
and  actuals  =  evlis(  rands(e),  a) 
elsif  is-if(e)  then 

if  eval(  cond(e),  a)  then  eval(  t-branch(e),  a) 
else  eval  (  f-branch (e)  ,  a)  endif 
endif  end 

and  rec  evils  =  proc(L,a)  Jaeqin 
if  null  (L)  then  <> 

else  const  eval  (L [i 1  , a) ,  evil s ( rest (L )  , a )  )  endif  end 

and  rec  aDoly  =  or oc (  closure,  actuals)  begin 
let  abs  =  ip(closure)  in 

let  env  =  pairlist  bvs(abs),  actuals,  eo(closure))  in 
eval (  body(abs),  env)  end 

and  apply-prim  =  proc(f,x)  beqin 
if  f='first'  then  first(xtil) 
elsif  f='cons'  then  const  xfi] ,  x[21  ) 
els i f  ... 
endif  end 

1  n  •  •  a 

Figure  4.  ^-List  Eval 
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The  interpreter  is  very  similar  to  the  interpreters  used  tor  LISP 
and  similar  lanquaqes.  To  clarify  its  operation,  several  exam¬ 
ples  will  be  presented.  In  these  examples  we  will  trace  the 
invocations  of  'eval'  and  'apply'  and  occasionally  ocher  func¬ 
tions. 


EXAMPLE  i:  reduction  of  >xy { cons (y , x ) }  ( <2  3>,  1). 

In  the  list  representation  this  is: 

E  =  <  ’  call  *  F  A> 

F  =  <'iambda'  <'x'  • y ' >  3> 

3  =  < ' pr im '  '  cons '  P> 

P  =  <<'var'  'y'>  <'var'  'x'>> 

A  =  «'ccnst'  <2  3>>  <'const'  i>> 

Eval (E  ,  <>)  : 

closure  =  eval(F,<>)  =  <'ciosure'  F  <>> 
actuals  =  evlrs(A,<>)  =  <<2  3>  i> 
appiy(  closure,  actuals  ): 
abs  =  F 

env  =  pa  lr  1  is  (  Cx'  'y'>,  actuals,  <>  ) 

=  <<’x'  <2  3>>  < ' y '  i>> 
aval (3 ,env) : 

actuals  =  evirs(  «'var'  'y'>  <’var'  'x’>>,  env  ) 

=  <1  <2  3 >> 

ippl y-prrm(  'cons',  <1  <2  3>>  ): 
cons (  1,  <2  3>  )  =  <1  2  3> 

EXAMPLE  2:  Reduce 

let  i  =  3  in 

let  f  =  >x{  prod(x,i)  }  in 
let  i  =  2  in 
f  (i) 

To  translate  this  to  list  representation  it  is  necessary  to  first 
eliminate  syntactic  sugar: 

Ai{  Af  {  >i{  f(i)  }  (2)  }  {  >x{prod  (x  ,  i)  }  )}(3). 

Notice  that  by  doinq  a  hand  reduction  of  this  we  can  determine 
that  the  correct  reduction  is  5.  For  the  sake  of  this  example  we 
will  assume  that  'eval'  can  evaluate  the  primitive  application 
'prod',  which  multiplies  two  numbers. 
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2  =  <  1  call  '  I  <<  'const.'  3>>  > 

I  =  X'lambda'  <'i'>  <'cail'  F  <:<>>  > 

F  =  <'lambda'  < '  i '  >  <'cali'  J  <<’ccnst'  2>>  >> 

J  =  C'iambda'  <‘x'>  C'caii'  <'var*  'i’>  <<’var’  'x’>>  >> 

X  =  <’ lambda'  <'x'>  P> 

P  =  C'prxm'  'prod'  <<'var*  'x'>  <  'var  1  'i'>>  > 

2va  1 (  2  ,  <>  )  : 
closure  =  <'c*csuta'  1  <>> 
actuals  =  <3> 

app*y(  closuxe,  actuals  ): 
abs  =  I 

env  =  <<  '  j.  '  3>> 

evai (  < ' call '  F  <X>>,  <<'x'  3  >>  ): 
closure  =  X'closure’  F  <  <  '  i  '  3>>  > 
actuals  =  ev*is(  <X> ,  <<'i'  3>>  ) 

=  <C>  where  C  =  C'ciosure'  X  <<'r'  3>>  > 
appiy(  closure,  actuals  ): 
abs  =  X 

env  =  < < 1 i 1  C>  < ' l '  3>> 
eval(  < ’call ’  J  <<'const'  2>>>,  env  ): 
closure  =  <’ closure'  J  <<'t'  C>  < ' i '  3>>  > 
actual s  =  <2> 

appiy(  closure,  actuals  ): 
abs  =  J 

env  =  <<  '  x  2>  C  t'  C>  < ' r '  3>> 

eval  (  <'ca*  J  <’var'  't'>  <<*var'  'i*>>  >,  env  ): 
closure  =  eval {  <'var'  'r'>,  env  )  =  C 
actuals  =  <2> 
apply(  closure,  actuals): 
abs  =  X 

env  =  pairlis(  <'x'>,  <2>,  ep(closure)  ) 

=  pa  x  r 1 r  s (  <’x'>,  <  2  >  ,  <  <  '  x  '  3>>  ) 

=  << ' x '  2>  <  '  x  '  3 >> 
eval (  P ,  env  ) : 

actuals  =  eval(  CC'var'  'x’>  <’var'  '  x '  >  >  ,  env  ) 

=  <2  3> 

ptxm-appiy(  'prod',  <2  3>  ): 
prod (2,3)  =  5 

Do  the  reduction  by  hand  to  be  sure  you  see  that  this  is  the 
riqht  answer. 

T.4.17  replacement  of  variables  by  f ixed  locations .  Observe 
chat  our  current  interpreter  spends  a  lot  of  its  time  searching 
association  lists  for  the  values  of  variables.  That  is,  the 
evaluation  of  C'var'  'x’>  in  the  environment  ’a'  requires  search¬ 
ing  'a'  for  a  pair  whose  first  element  is  'x'.  Such  searching  is 
expensive  on  most  conouters,  so  we  will  develop  a  method  or 
interpreting  the  lambda  calculus  which  does  not  require  it.  In 
oarticular,  we  will  replace  searching  by  array  subscripting, 


51 


which  is  much  more  efficient.  we  will  develop  the  Drocess  ror 
single  variable  abstractions  initially  and  later  extend  it  tor 
multiple  variables.  Consider  an  abstraction  '/xfEl'  in  some 
environment  The  closure  formed  from  evaluating  this 
abstraction  will  be 


<’closure'  <'lambda'  Ox'>  <...>  >. 


When  this  closure  is  applied  to  an  ooerand  value  'u'  its  evalua¬ 
tion  will  always  take  the  form 

eval (  5,  << ' x '  u>  ...>  )  . 


Motice  that  the  bound  variable  of  the  abstraction  being  evaluated 
will  always  occupy  the  first  pair  of  the  environment.  Therefore 
there  is  really  no  reason  to  search  for  this  variable  since  we 
know  where  it  is.  Since  the  abstraction  we  chose  was  arbitrary, 
this  can  be  seen  to  be  true  for  all  abstractions .  In  fact,  we 
find  that  it  is  true  for  all  variables  that  we  can  determine  the 
position  of  each  variable  in  the  environment  by  counting  the 
number  of  "scoping  lines"  that  must  be  crossed  in  getting  from  a 
use  of  the  variable  to  its  definition.  This  number  is  called  the 
static  distance  of  a  variable  from  its  definition,  and  is  for¬ 
mally  defined  to  be  the  number  of  scopes  containing  the  use  of 
the  variable  that  do  not  contain  its  definition  (binding 
occurence).  For  instance,  in 
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the  static  distances  of  the  variables  from  their  definitions  are 
indicated.  For  'f  it  is  2,  for  'x'  it  is  i,  for  the  leftmost 
’ i *  it  is  i  and  for  the  rightmost  'i'  it  is  2.  Since  we  know 
where  each  variable  occurs  in  the  association  list,  we  can 
replace  expressions  of  the  form  <'var'  'x’>  with  expressions  of 
the  form  <' var'  n>  where  n  is  the  position  of  variable  'x'  in  the 
environment.  This  value  n  will  be  called  the  vn  or  va r iable 
position ,  as  indicated  in  the  new  structure  declaration  for  vari¬ 
ables: 


structure  var:  (vo) 

Since  we  no  longer  use  the  variable  names  to  look  them  up  in  the 
environment,  we  can  eliminate  them  and  represent  the  environment 
as  a  list  of  values  rather  than  an  association  list.  For 
instance  the  association  list 

<  <’x'  2>  Cy'  'Monterey’>  <’z'  <0  i  2>>  > 


r 
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will  he  simplified  to 

<  2  'Monterey'  <0  1  2>  >. 

Then,  looking  up  <'var'  n>  in  environment  'a’  is  simply  accom¬ 
plished  by  afnl.  Since  variables  are  no  longer  needed,  the  bound 
variable  list  can  also  be  eliminated  from  the  representation  of 
abstractions.  For  instance  *>x { cons (x , <> ) } '  is  represented  bv 

<*lambda'  <’prim’  'cons'  <'var'  i>  <’const'  <>  >>  >. 

The  new  structure  definition  for  abstractions  is: 

structure  lambda:  (body) 

This  process  of  converting  variables  from  names  to  numeric  loca¬ 
tions  is  one  that  is  usually  oerformed  by  a  translator  or  com¬ 
piler.  Since  we  are  translating  bv  hand  from  the  lambda  calculus 
to  its  list  representation ,  we  must  do  this  counting  ourselves. 
It  is  generally  true  of  programming  language  implementations 
that,  as  we  have  done  here,  the  run-time  efficiency  of  a  program 
can  be  increased  by  doing  more  work  at  compile  time. 

There  are  only  a  few  simple  changes  necessary  to  convert 
'eval*  to  use  the  new  numeric  variables  --  ail  simplifications. 
The  rule  for  ' var's  is  simply  altered  to  subscript  the  requred 
value  out  of  the  environment: 

eisif  is-var  then  a(vp(e)l 

The  only  other  change  is  to  the  'apply'  procedure:  since  environ¬ 
ments  are  simple  lists  of  values  the  environment  of  evaluation  is 
constructed  by  appending  the  operand  to  the  front  of  the  environ¬ 
ment  of  definition. 

and  rec  apply  =  proc  (  closure,  actuals)  begin 
let  abs  =  ip(closure)  in 

let  env  =  append (  actuals,  ep(closure)  )  in 
eval(  body (abs),  env)  end 

To  clarify  these  ideas  we  will  trace  the  evaluation  of  the  lambda 
expression: 

>i{  >f  {  Ai  {  f(i)  1(2)  }(  >x(  prod  (i  ,x)  }  )  }(3) 

This  is  represented  by  the  list: 
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E 

I 

F 

J 

X 

P 


< ' call '  I 
< ' lambda ' 
<' lambda  1 
< 1  lambda ' 
< '  lambda ' 

< ' pt lm '  * 


<<'ccnsc'  3>>  > 

< 1 caii '  F  <X>>  > 

<  *0311'  J  <<'consL'  2  >  >  >> 

<  '  call 1  <  1  var  '  2>  «'vat'  j.>> 
P> 

prod'  <<’var'  2>  < 'var 1  i>>  > 


>> 


Svai (  £  ,  <>  )  : 

appiy(  Cciosure'  1  <>>,  <3>  ): 
env  =  append(  <3>,  <>  )  =  <3> 
evax(  <'caii'  F  <X>>,  <3>  ): 

Evaluation  proceeds  much  as  betote,  until  the  stage  when  the 
application  t(i)  must  be  evaluated: 

evai(  C'caii1  <’var'  2>  << 'var '  i>>  >,  <2  C  3>  ): 
closure  =  evai(  < 'var 1  2>,  <2  C  3>  )  =  C 

actuals  =  evlis(  <<'var'  ±>>,  <2  C  3>  )  =  <2> 
apply (  C ,  <2>  ) : 

env  =  append(  <2>,  <3>  )  =  <2  3> 
eval (  P,  <2  3>  )  : 

actuals  =  evlis(  <<’var'  2>  <’var'  i>>,  <2  3>  ) 

=  <3  2> 

pr im-appiy (  'prod',  <3  2 >  )  =6 


1.4.18  static  nesting  level .  The  approach  used  above  is  based 
on  the  replacement  by  the  translator  of  variable  names  by  numbers 
indicating  the  static  distance  or  the  use  of  the  variable  from 
its  definition.  This  number  will  vary  from  one  use  of  a  variable 
to  another.  For  instance,  in 

>*x{  cons(  x,  >y{  const  x,  append(y,y)  )  }(<A  3>)  )  }  (C) 

the  first  use  of  'x'  will  be  translated  by  <'var'  i>  while  the 
second  use  of  'x'  will  be  translated  by  <’var'  2>.  The  transla¬ 
tion  process  would  be  a  little  simpler  if  a  single  number  was 
always  associated  with  ail  uses  of  a  given  variable.  We  can  do 
this  by  using  the  static  nesting  level  of  the  definition  of  the 
variable  as  this  number.  The  static  nesting  level  of  the 
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definition  of  a  variable  is  one  nore  than  the  number  or  scooes  in 
which  that  definition  of  the  variable  is  nested.  In  the  diagram 
below,  the  static  nesting  levels  of  the  variables  are  indicated: 


The  above  diagram  also  indicates  the  static  nesting  level  of  the 
uses  of  variables.  Notice  that  the  static  nesting  level  of  the 
use  of  a  variable  is  the  sum  of  the  static  nesting  level  of  its 
definition  and  the  static  distance  to  that  use.  Therefore  we  can 
calculate  the  static  distance  from  the  static  nesting  level  or 
vice  versa.  This  means  that  one  way  to  alter  'eval'  to  use 
static  nesting  levels  is  to  alter  it  to  compute  the  static  dis¬ 
tance  and  then  to  extract  the  value  from  the  environment  in  the 
previous  way.  There  is  a  simpler  way,  however,  since  we  can  so 
construct  the  environment  that  the  static  nesting  level  can  be 
used  to  directly  access  the  environment.  To  understand  the  way 
this  is  done  notice  that  with  our  present  'eval'  the  "innermost" 
variable  is  first  in  the  environment  and  the  "outermost"  variable 
is  last  in  the  environment.  To  make  most  convenient  use  of 
static  nesting  levels  we  want  to  construct  the  environment  so 
that  the  "outermost"  variable  (i.e.  that  at  static  nesting  level 
1)  is  the  first  (i.e-.  a(il)  and  the  "innermost"  is  last.  This  is 
accomplished  by  simply  concatenating  the  latest  variable  values 
to  the  right  of  the  environment  rather  than  the  left.  The  only 
required  alteration  to  the  interpreter  is  to  switch  'actuals', 
and  ' ep(ciosure) '  in  apply: 

let  rec  apply  =  proc  (  closure,  actuals)  begin 
let  abs  =  io(closure)  in 

let  env  =  append (  ep(closure^,  actuals  )  in 
eval (  body(abs),  env)  end 

The  translation  of  lambda  expressions  into  the  list  representa¬ 
tion  is  simplified  since  a  variable  is  always  translated  in  the 
same  way.  The  translation  of  our  previous  example  is: 

J  =  C'iambda'  C'cail'  C'var'  2>  <<’var'  3>>  >> 

P  < 'pilin'  'prod'  <<'var'  x>  <'vat  '  2>>  > 

EXERCISE :  Trace  the  evaluation  or  this  list. 
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1.4.19  multiple  parameters .  To  keep  the  discussion  simple,  we 
have  only  been  discussinq  the  implementation  of  abstractions  and 
applications  with  a  single  parameter.  We  will  now  extend  our 
implementation  to  handle  more  than  one  parameter. 

In  our  current  implementation  (usinq  static  nestina  levels) 
the  environment  is  represented  by  a  list  of  the  form 


<V1  v2 


•  vn> 


where  v-  is  the  value  of  the  variable  bound  at  static  nesting 
level  i.  To  handle  multiple  parameters  we  will  simply  replace 
each  of  these  values  with  a  list  of  the  values  bound  at  each 
static  nesting  level.  That  is,  an  environment  has  the  form 


<ar^  a r-, 


a  r  > 
n 


where  each  ar-  is  called  the  activation  record  (or  call  frame ) 
for  static  nesting  level  i.  An  activation  record  is  defined  to 
be  all  -jl  the  information  relevent  to  a  call  of  a  function.  Fach 
activation  record  has  the  form 

<  V-J  V-J  ...  V  > 
x  £  m 

where  the  v,s  are  the  values  of  the  variables  declared  at  the 
static  nestinq  level  corresponding  to  the  activation  record.  To 
access  a  variable  it  is  now  necessary  to  use  two  coordinates, 
(eo,vp) ,  where  the  environment  oart  (eo)  is  the  stacic  nesting 
level  of  the  activation  record  containing  the  variable,  and  the 
variable  part  (vp)  is  the  position  of  the  value  of  the  variable 
within  that  activation  record.  For  example,  if  we  are  in  the 
environment 


<  <1  2  3  >  <  '  A  1 


'C’>  <4  'D'  <5  F>  '  F  '  >  > 


then  the  (eo,vp)  pair  (2,1)  will  refer  to  'A',  the  pair  (3,2) 
will  refer  to  '0'  and  the  pair  (3,3)  will  refer  to  <S  F>.  In 
particular,  if  'a'  is  the  environment,  then  'a[epl[vp1'  is  the 
value  of  the  variable  corresponding  to  the  pair  (eo,vp) .  In 
order  to  make  use  of  this  new  structure  for  the  environment,  it 
is  necessary  to  translate  variables  into  lists  of  the  form 

< ' var '  ep  vp> 

where  (ep,vp)  is  the  location  of  the  variable.  This  corresponds 
to  the  structure: 


structure  var:  (ep,  vp) 


Therefore,  to  handle  multiple  parameters,  the  rule  for  'var's 


66 


'eval'  must  be  changed  to: 

elsif  is-var(e)  then  arfvo(e)1 
where  ar  =  a ( ep  (e ) 1 

The  next  issue  to  be  addressed  is  the  construction  of  these 
environments  by  the  'apply'  procedure.  If  the  environment  of 
definition  from  the  closure  is 


<ari 


arn> 


and  the  actual  parameters  of  the  apolication  are 


<v-  v-  . . 
j.  I 


V  > 
m 


then  the  environment  in  which  the  body  of  the  abstraction 
evaluated  should  be 


<ar  i 


ar„  <v<  v, 
n  i .2. 


vm>>. 


That  is,  a  new  activation  record,  arn+i=<v-  •**  vm'> '  is  na^e  the 
new  last  element  in  the  environment.  If  +  ep’  is  the  environment 
of  definition  and  1 x’  is  the  actual  parameter  list,  then 

consR  (  ep,  x  ) 

where  consR  =  proc(L,x){  append (  L,  cons(x,<>)  )  } 

will  construct  the  environment  of  evaluation.  The  appropriately 
modified  ’apply'  is: 

let  rec  apply  =  proc  (  closure,  actuals)  begin 
let  abs  =  ip(closure)  in 

let  env  =  consR (  ep(closure) ,  actuals)  in 
eval(  body(abs),  env  )  end 

and  consR  =  oroc(L,x){  append(  L,  cons(x,<>)  )  } 

The  complete  'eval'  is  shown  in  the  next  figure.  To  demonstrate 
the  operation  of  the  new  'eval',  we  will  trace  the  reduction  of 

>xv{  Xzi  z*z  +  x  }  (x+y)  }  (2,3) 

First  we  translate  the  lambda  expression  into  our  list  represent 
tation,  numbering  the  lambdas  as  before: 

Ccail  <lambda ( 1 ) 

Ccall  <lambda(2)  <prim  sum  <prim  prod  <var  2  i>  <var  2  i>> 

<var  1  i>>  > 

<prim  sum  <var  1  1>  <var  1  2>>  >> 

<const  2>  <const  3>> 


"X" 
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let  rec  Eval  *  oroc(e,a)  begin 

it  is-const(e)  then  const-val(e) 

elsit  is-var(e)  then  arTvpfe)!  where  ar  =  a(eo(e)l 
eisit  i s-lambda ( e)  then  closure(  e,  a) 
elsit  is-prim(e)  then  apply-orim(  rator(e),  actuals) 
where  actuals  =  evlis(  rands(e),  a) 
elsit  is-call(e)  then  apply (  closure,  actuals) 
where  closure  =  eval(  rator(e),  a) 
and  actuals  =  evlis(  rands(e),  a) 
elsit  is-if(e)  then 

it  eval  (  cond(e),  a)  then  eval  (  t-branch  (e)  ,  a) 
else  eval(  f-branch(e),  a)  endit 
end  it  end 

and  rec  evlis  =  proc(L,a)  begin 
it  null(L)  then  <> 

else  cons  (  eval  (L [11 ,al  ,  evlis (rest  (L) , a)  )  endit  end 

and  rec  apply  =  oroc  (  closure,  actuals)  begin 
let  abs  =  ip(closure)  in 

let  env  =  consR(  ep(closure),  actuals)  in 
eval (  body(abs),  env)  end 

and  apply-prim  =  proc(£,x)  begin 
it  c=' first'  then  first (xf 11) 
elsit  f='cons'  then  cons(  x(il ,  x[2]  ) 
elsit  ... 
endit  end 
in  ... 

and  consR  *  proc(L,x){  append (  L,  cons(x,<>)  )  } 

Figure  5.  Eval  for  Fixed-location  Variables 


Here  we  see  that  'x',  'y'  and  ’z'  have  been  translated  as  ' <var  i 
i>',  '<var  1  2>'  and  ' <var  2  !>',  respectively,  on  the  basis  of 
their  static  nesting  levels  and  their  positions  at  that  level, 
i.e.  their  (ep,vp)  coordinates.  The  trace  follows: 
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£  *  <  'call  *  X  <<'  const ‘  2>  <  'consc1  3>>  > 

X  3  <'iambda'  <'caii'  Z  <S>>  > 

2  3  <'iambda’  Optim’  'sum'  <P  <'vat'  1  i>>  >> 

S  3  <  '  pt  i.rn  *  'suin'  <<’var'  i  i>  <'var'  i  2>>  > 

P  *  <'ptira'  'prod'  <<'vat '  2  i>  <’var'  2  I>>  > 

Evai (  S ,  <>  ) : 

appiy(  C'cicsurs'  X  <>  >,  <2  3>  ): 
env  -  consR(  <>  ,  <2  3>  )  =  <<2  3>> 
evai  (  < ’ caii 1  Z  <S>>,  <<2  3>>  ): 
actuals  =  eviiS{  XX'prim'  'sum' 

«'var'  1  1>  < '  vat  '  i  2>>  >>,  <<2  3>>  ) 
=  <  sum ( 2 , 3 )  >  3  <5> 
appiy(  <'closure'  Z  <<2  3>>  >,  <5>  ): 
env  =  consR (  <<2  3>>,  <5>  )  3  <<2  3>  <5>> 
evalf  X'pttm'  'sum'  <P  <’vat 1  1  i>>  >,  <<2  3>  <5>>  ): 
actuals  3  eviis(  <P  <'var*  1  i>>,  <<2  3>  <5>>  ) 

=  <  evai (P,<<2  3 > < 5 > > )  2  > 

It  is  new  necessary  to  compute  the  subexpt ess i on ,  eval(?,<<2 

3 > <5 > > )  . 

evai (  ?,  <<2  3>  <5>>  ) : 
actuals  =  eviis(  <<’vat 1  2  i>  <'var'  2  i>>, 

<<2  3>  <5>>  ) 

3  <5  5> 

prj.m-appiy(  'prod',  <5  5>  )  3  25  ,  hence, 
actuals  =  <25  2> 

ptrm-appiy(  'sum',  <25  2>  )  3  27 

You  will  recall  that  there  were  two  possible  versions  of  the 
single-oarameter  'evai':  one  which  used  static  nesting  levels  and 
one  which  used  static  distances.  There  are  also  two  possible 
versions  of  the  multiple-parameter  version  of  'evai':  we  can  use 
either  static  nesting  levels  or  static  distances.  When  we  inves¬ 
tigate  implementations  of  the  lambda  calculus  further,  later,  we 
will  find  that  there  are  circumstances  when  it  is  better  to  use 
the  static  distance  and  other  circumstances  when  it  is  better  to 
use  the  static  nesting  level.  These  are  similar  to  imolementa- 
tion  techniques  called  "static  chains'’  and  "disolavs"  .  which  are 
discussed  later. 

EXERCISE :  Translate  the  lambda  exoression 

>,xy{  Azf  z*2  +  x  }  (x+y)  }  (2,3) 

into  the  list  reor esentation  using  static  distances  instead  of 
static  nesting  levels.  Make  the  aoprooriate  changes  to  'evai'  so 
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I  .5  Runtime  Organization 
I  .5.1  Goals  Defined 

In  this  chapter  we  will  study  the  stack  implementation  of 
the  extended  lambda  calculus.  That  is,  we  will  study  how  SL C  can 
be  translated  into  the  instructions  of  conventional  computers  by 
usinq  the  data  structure  known  as  a  stack .  Since  all  block- 
structured  lanouages,  when  stripped  of  their  syntactic  suoar,  are 
essentially  the  lambda  calculus,  you  will  be  learning  how  to 
implement  these  languages.  (This  important  class  of  languages 
includes  Algol,  Pascal,  PL/I  and  Ada.) 

I  .5  .  ?  Stacks 

The  data  structure  used  on  most  computers  for  implementina 
block-structured  languages  is  the  stack .  Stacks  derive  their 
name  from  the  oush-down  stacks  that  are  often  used  for  dispensing 
plates  in  cafeterias  (figure  i)  . 


Figure  1.  The  Original  Push-Down  Stack 

with  these  devices,  each  time  a  plate  is  removed  from  the  too , 
the  stack  pops  up  to  bring  the  next  plate  to  the  too.  Con¬ 
versely,  whenever  a  plate  is  placed  on  the  too  of  the  stack,  it 
pushes  down  the  plates  already  there.  Thus,  a  particular  Plate 
can  be  pushed  onto  the  stack,  and  have  other  plates  pushed  on  too 
of  it,  thereby  hidinq  it.  Rut  if  these  olates  are  later  popped 
off,  then  the  plate  we  started  with  will  again  be  at  the  too  of 
the  stack.  This  property,  being  able  to  save  things  (or  informa¬ 
tion)  by  pushing  them  on  a  stack,  makes  the  stack  data  structure 
particularly  valuable  in  programming  lanquage  implementation. 
Stacks  are  also  know  as  oush-down  stores ,  deques  and  LIFms  (which 
means  "last-in,  first-out"  and  is  Pronounced  "lie-foe").  To  see 
the  relevence  of  stacks  to  programming  language  implementation, 
we  must  next  Investigate  postfix  instructions. 
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I  .5.3  postf  i  x  Instructions 

we  have  seen  how  exoressions  can  be  written  in  cunctional 
torm.  For  instance. 


x  +  ab(y-z) 


can  be  written 


sum{  x,  pr od (  prod(a.b),  dif(y,z)  )) 

when  an  expression  such  as  this  is  written  without  parentheses  it 
is  call  prefix  notation  or  Polish  notation  (after  Jan  fe 
ukasiewicz,  the  Polish  logician  who  invented  it).  The  above 
expression  written  in  prefix  notation  is: 

+  x**ab-yz 

One  of  the  important  properties  of  Polish  notation  (and  the  rea¬ 
son  it  was  invented)  is  that  it  is  never  necessary  to  use 
parentheses  with  it;  it  is  ofen  called  parentheses  free  nota- 
tion . 


The  reason  Polish  notation  is  also  called  Prefix  notation  is 
that  the  operator  is  written  before  (pre-)  its  operands.  S.g. 

+  x  y 

The  usual  mathematical  convention  is  called  infix  notation 
because  the  operator  is  written  between  (in-)  its  operands: 

x  +  y 

It  should  be  obvious  that  if  we  wrote  the  operator  after  its 
operands,  then  we  would  be  writing  in  postfix  or  reverse  polish 
notation.  Reverse  Polish  notation  is  more  important  to  computer 
scientists  than  Polish  notation  because  reverse  Polish  can  be 
evaluated  easily  by  using  a  stack. 

You  may  be  familiar  with  "PPM”  (or  Reverse  Polish  Notation) 
calculators,  such  as  those  manufactured  by  Hewl i tt-Packa rd  and 
National  Semiconductor,  with  these  calculators  exoressions  to  be 
evaluated  are  entered  in  postfix  notation  and  temporary  results 
are  held  in  a  stack.  Por  instance,  to  calculate 

2  +  5  *  in, 

which  is  postfix  notation  is 


2  5  10 


*  +, 
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we  would  hit  the  keys: 

CD  cn  G3  [ZD  DD  GD 

The  foilwing  diagram  shows  how  the  stack  holds  the  intermediate 
results. 


Notice  how  the  stack  holds  the  operands  before  the  oneration 
(e.q.  5  and  10)  and  the  results  after  the  operation  (e.g.  50). 


I  .5.4  The  L '-Machine  Arch i tecture 

We  will  now  investigate  a  computer  with  a  stack  architec¬ 
ture,  i.e.  a  computer  that  uses  a  stack  for  the  evaluation  of 
postfix  instructions.  Although  the  L-Machine  is  not  a  real  com¬ 
muter,  it  is  essentially  a  simplification  of  several  commercially 
available  machines. 

The  L-Machine  has  three  registers  (high  soeed  memory  loca¬ 
tions)  ,  called  SP,  SP  and  IP,  and  a  memory  addressed  by  consecu¬ 
tive  natural  numbers  that  can  hold  both  data  and  instructions. 
The  register  names  are  mnemonic: 

SP  -  Stack  Pointer 

Sp  -  Environment  Pointer 

IP  -  Instruction  Pointer 

The  SP  register  holds  the  address  of  the  top  of  the  stack,  the  SP 
register  holds  the  address  of  the  current  activation  record 
(explained  further  later)  and  the  IP  register  holds  the  address 
of  the  next  instruction  to  be  executed.  The  L-Machine's  storage 
architecture  is  summarized  in  the  following  figure. 

Peaisters  Memory 


Figure  2.  L-Machine  Storage  Architecture 


73 


The  L-Machine  has  some  25  instructions  that  it  is  able  to 
execute.  '^e  will  discuss  each  or  these  in  the  following  para¬ 
graphs  and  indicate  their  ooeration  with  diagrams. 

1  PUSH .  The  'PUSH'  operation  pushes  a  constant  value 
onto  the  stack.  That  is,  it  k  is  any  constant  (i.e.,  number, 
string,  Boolean  or  list),  then  'P'JSH  k'  will  increment  the  SP 
register  and  store  k  in  the  memory  location  addressed  by  SP.  In 
diagramatic  form: 


Stack 


PUSH  k 

2  PUSHEP .  The  "PUSHEP"  operation  pushes  the  current  con¬ 
tents  of  the  EP  register  onto  the  stack: 


PUSHEP 


3  POP.  The  't>OP'  instruction  discards  elements  from  the 
top  of  the  stack.  That  is,  ’POP  k'  will  pop  the  too  k  elements 
from  the  stack  and  discard  them.  E.g.. 


POP  3 


4  SETEP .  The  'SETEP'  operation  pops  a  value  from  the 
stack  and  places  it  in  the  EP  register. 


SETEP 


5  mark .  The  'MARK'  ooeration  moves  the  current  contents 
of  the  SP  register  into  the  EP  register.  The  effect  of  this  is 
to  remember  the  location  of  the  current  top  of  the  stack. 
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MARK 


5  COPY .  The  'COPY'  operation  copies  a  value  from 
a  specified  location  of  the  stack,  and  places  it  on  too 
stack-  For  instance,  'COPY  3'  conies  the  value  that  is 
from  the  too  of  the  stack  and  pushes  it: 


within 
of  the 
third 


a 

(i) 

(2)  => 

■ 

a 

(3) 

a 

(4) 

L — j 

COPY 

3 

7  SWAP .  The  'SWAP'  operation  exchanges  two  elements  of 
the  stack.  For  instance,  'SWAP  2,5'  swaps  the  second  and  fifth 
elements  from  the  top  of  the  stack: 


(1) 

a 

(2) 

b 

(3)  => 

(4) 

b 

(*5> 

a 

(*) 

_ 

- 

SWAP  2,5 

S  PAIR.  The  'PAIR'  operation  combines  the  top  two  stack 
elements  into  one;  the  two  elements  become  the  left  and  right 
halves  of  the  resulting  value.  These  two  values  can  be  extracted 
by  'LEFT'  and  'RIGHT',  described  below. 


PAIR 
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9  LEFT .  RIGHT.  The  ‘LEFT'  operation  extracts  the  let t 
halt  ot  a  value  constructed  by  •PAIR': 


LEFT 


The  'RIGHT'  operation  extracts  the  right  half. 

.10  VAL .  The  'VAL'  operation  access  the  current  contents 
of  a  location  in  memory.  The  'VAL'  operation  takes  an  address 
from  the  top  of  the  stack  and  replaces  it  with  the  contents  of 
the  memory  location  at  that  address. 


a 


11  SET.  mhe  'SET' 
of  a  memory  location  to  a 
an  address  from  the  top  of 
memory  location  with  that 
of  the  stack. 


operation  chanqes  the  current  conte 
specified  value.  It  takes  a  value 
the  stack  and  stores  the  value  in 
address.  The  value  is  left  on  the 


nts 

and 

the 

top 


i 


S  tack> 


Memo  ry- 


12  ADD ,  SUQ ,  MUL ,  DIV.  These  ODerations  perform  addi- 
cion,  subtraction,  multiplication  and  division.  The  operands  are 
the  two  top  elements  of  the  stack,  which  are  replaced  by  the 
results  of  the  operation.  This  is  essentially  like  an  RPN  calcu- 
lato  r . 


ADO 

(S'jg,  MUL,  DIV  Similar) 


Any  other  primitive  operations  with  which  we  wish  to  equip  the 
L-Machine  (such  as  the  relationals,  BO,  me,  GT,  etc.)  would 
operate  analogously. 

13  IF .  The  'I5”  operation  performs  a  iump  if  the  too  of 
the  stack  is  'true'.  In  particular,  the  operation  'I*  k'  pops 
the  stack  and,  if  this  value  is  'true',  transfers  to  the  instruc¬ 
tion  at  location  k  (by  placing  k  in  the  IP  register).  If  the  too 
of  the  stack  is  false  then  execution  continues  at  the  instruction 
which  follows  the  'IF'. 


bl  => 


c=k  if  b=true 
c=a  if  b=faise 
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14 


;otp  . 


The 


GOTO'  operation  transters  cOntro' 


to 


another  location  bv  placing  its  operand  in  the  IP  register 


IP 


=  >  IP 


goto  k 


15  GOI_.  'T'hi e  'GOI'  operation  is  an  "indirect  goto 
is,  the  too  of  the  stack  is  a  value  that  is  used  as  the 
of  the  next  instruction  to  execute.  This  is  accompl i shed 
ping  the  stack  into  the  IP  register.  GOI  is  used  instead 
when  the  destination  address  must  be  computed  while  the 
is  running. 


.  That 
address 
bv  poo* 
or  GOTO 
pronram 


I  .5.5  Act  i  vat  ion  Pecord  Structure  As  we  learned  in  Chapter  I  . 6 
the  activation  record  is  the  implementation  mechanism  that  embo¬ 
dies  the  idea  of  the  local  environment  of  a  computation.  Activa¬ 
tion  records  will  also  be  important  to  our  compiled  implementa¬ 
tion  of  the  lambda  calculus,  so  in  this  section  we  will  study 
their  implementation  on  a  stack.  You  will  remember  that  we 
defined  an  activation  record  to  be  all  of  the  information 
r el event  to  a  call  of  a  procedure.  In  the  Fval  interpreter  this 
was  just  the  values  of  the  bound  variables  or  the  function.  r're 
will  see  below  that  in  the  compiled  implementation  additional 
information  must  be  included  in  the  activation  record. 

'"onsider  the  following  lambda  expression,  which  we  have 
already  investigated  several  times: 

let  i  =  3  in 

let  t  =  proc(x)f  x*i  }  in 
let  i  =  2  in 
f  (i) 

This  can  be  represented  by  the  contour  diagram  in  figure  3.  In 
this  diagram  we  have  drawn  solid  arrows  from  each  contour  to  the 
statically  enclos i ng  contour.  These  arrows  are  called  stat ic 
links.  A  static  chain  is  any  contiguous  sequence  of  static 
links,  for  instance  from  the  i=2  contour  to  the  f=>{xi}  contour 
to  the  i=3  contour.  what  the  static  chain  Provides  is  a  search 
path  for  looking  up  variables.  For  instance,  if  we  are  executing 
in  the  environment  indicated  by  the  it  in  the  above  diagram,  and 
wish  to  evaluate  ' i ’ ,  then  we  proceed  as  follows.  pirst  look  in 


figure  3. 


Contours 


the  local  environment:  is  it  defined  here?  Mo,  only  'x'  is 
defined  here,  so  follow  the  static  link  to  the  enclosing  environ¬ 
ment:  is  it  defined  here?  Yes,  the  value  of  'i'  is  3  .  If  it 
hadn't  been  defined  here  we  would  have  followed  the  static  link 
and  continued  searching  in  the  statically  enclosing  environment. 

In  our  compiled  imDlementation  of  the  lambda  calculus, 
activation  records  will  be  stored  in  a  stack.  we  will  use  static 
links  to  find  our  wav  from  one  activation  record  to  the  next. 
por  instance,  when  we  begin  executina  ’f(i)’  in  contour  (c) ,  the 
stack's  structure  will  be: 


The  activation  records  correspond  exactly  to  the  contours  encoun¬ 
tered  in  following  the  static  chain  from  ’f(i)'.  The  EP  register 
always  points  to  the  beginning  of  the  static  chain.  Mow,  suppose 
we  call  the  function  bound  to  'f'.  This  amounts  to  entering  the 
contour  (d  )  to  execute  'x*i'.  The  activation  record  tor  'f'  will 
be  oushed  onto  the  top  of  the  stack.  Mote,  however  that  the 
static  chain  reflects  the  correct  environment  for  'x*i': 


pigure  5.  Inside  f 


In  particular,  when  we  come  to  evaluate  'i',  we  will  follow  the 
static  chain  to  activation  record  (a),  which  binds  ’  i ’  to  3. 
When  the  function  ' f ’  is  exited  the  activation  record  (d)  must  be 
deleted  from  the  stack  and  the  situation  restored  to  that  of  fig¬ 
ure  4.  To  do  this  it  is  necessary  to  regain  access  to  activation 
record  (c)  ,  the  activation  record  of  the  caller  of  ' f ' .  Doing 
this  requires  another  link,  the  dynamic  link,  from  each  activa¬ 
tion  record  to  its  caller.  The  sequence  ot  dynamic  links  is 
called  the  dynamic  chain .  In  figure  h  we  see  the  same  situation 
as  in  figure  5  (i.e.  inside  f)  exceDt  that  the  dynamic  chain  is 
shown . 
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Motice  chat  the  dynamic  link  always  points  to  the  next  lower 
activation  record  in  the  stack. 

So  tar  we  have  seen  that  the  activation  record  contains 
three  nieces  or  information:  the  values  of  the  bound  variables, 
the  static  link  and  the  dynamic  link.  There  is  one  other  type  ct 
information  that  is  useful  to  include  in  the  activation  record: 
temporaries,  ''’hen  we  discussed  the  stack  evaluation  of  postrix 
exoressions  we  saw  that  the  stack  holds  oDerands  until  it  is  time 
to  onerate  on  them.  We  will  use  the  stack  for  the  same  Duroose 
here. 

The  actual  format  we  will  adopt  for  activation  records  is 
not  the  same  as  we  have  investiqated  so  far.  The  differences  are 
not  important,  however;  we  have  merelv  reorganized  the  fields  of 
the  activation  record  to  make  it  more  convenient  to  access  them 
with  the  instructions  of  the  L-vachine.  If  we  were  compiling  the 
lambda  calculus  for  some  other  machine  then  some  other  arrange¬ 
ment  might  be  better.  The  important  thing  is  the  information  the 
activation  record  contains,  irrespective  of  its  arrangement: 

*  access  to  local  environment  (values  of  bindings) 

*  access  to  alobal  environment  (static  link) 

*  access  to  caller  (dynamic  link) 

*  temporaries 

This  information  must  be  in  any  activation  record.  The  format  we 
will  use  for  the  L-^achine  is  shown  in  figure  7. 


temporaries 


static  link 
dynamic  link 

i 

ei  ;  i  o 
parameter  rT 


oarameter  1 


Stack-^ 

figure  7.  Activation  Record  Format 
I  .5  .  ^  Translation  to  L-Oode 


Tn  this  section  we  will  discuss  the  L-Oode  (L-Machine 
instruction)  translations  tor  each  construct  in  the  extended 
lambda  calculus.  To  aid  this  discussion  we  will  use  the  notation 
A(e]  to  denote  the  L-Code  translation  ot  the  lambda  expression  e. 
For  instance, 

Af  25  ]  =  PUSH  25 

The  translations  we  will  investiqate  in  the  rest  of  this  section 
are  not  unique;  different  machines  would  suqqest  different  code 
sequences;  there  are  even  different  ways  or  accomplishing  the 
same  thing  on  the  L-Nachine.  The  important  issue  is  not  the  par¬ 
ticular  instructions  presented  here,  but  rather  the  information 
flow  required  to  execute  the  lambda  calculus  constructs.  Since 
the  lambda  calculus  forms  a  deep  structure  for  most  programming 
languages  we  are  essentially  studying  the  implementation  methods 
cor  most  programming  languages. 

1  Constants  The  translation  of  variables  is  the  sim¬ 
plest,  since  all  we  have  to  do  is  to  push  the  constant  on  the 
stack.  For  instance, 

A?25)  =  PUSH  25 
/.Chat']  =  PUSH  ’hat’ 

A(<i  < ' hat '  2>>]  =  PUSH  <1  < ' ha t '  2>> 
or  in  general,  for  any  constant  c. 

Ate]  =  PUSH  c 

2  Variables  In  the  discussion  of  the  Rval  interpreter  we 
saw  the  use  of  (eo,vp)  pairs  to  locate  variables  within  the 
environment.  We  will  do  the  same  with  our  compiled  implementa¬ 
tion:  the  eo  will  locate  the  activation  record  holding  the  vari¬ 
able  and  the  vp  will  locate  the  variable  within  that  activation 
record.  The  static  distance  method  of  measuring  the  eo  will  be 
used  . 


First,  consider  how  we  get  to  the  activation  record  in  which 
the  variable  resides:  if  eo=l  then  the  variable  resides  in  the 
current  activation  record,  which  is  pointed  to  by  the  RP  regis¬ 
ter.  If  eo=2  then  the  variable  resides  in  the  next  most  enclos¬ 
ing  activation  record,  which  we  reach  by  followina  one  link  ot 
the  static  chain  form  the  current  activation  record.  It  eo=3 
then  we  must  follow  two  links  of  the  static  chain.  In  qeneral, 
we  must  follow  ep-i  links  to  get  to  the  activation  record  con¬ 
taining  variable  (eo,vp). 

Now  let  us  consider  the  L-Code  required  to  follow  the  static 
chain.  Our  goal  will  be  to  get  the  address  of  the  activation 


record  ?d  onto  the  top  of  the  stack.  Consider  the  case  ep=i.  In 
this  case  the  activation  record  is  the  current  one,  so 

P'JSHEP 

will  push  its  address  onto  the  stack. 

Now  consider  the  case  here  we  must  follow  the  static 

chain  one  link.  Recall  that  both  the  EP  register  and  the  static 
links  always  point  to  the  static  link  field  of  an  activation 
record.  See  figure  8. 


Figure  8.  The  Static  Chain 

Hence,  after  performing  P'JSHEP  the  too  of  the  stack  is  the 
address  of  the  static  link  for  the  current  activation  record.  We 
can  use  VAL  to  load  the  contents  of  this  location,  i.e.  to  get 
the  address  of  the  next  activation  record  in  the  static  chain. 
Hence , 

P'JSHEP 

VAL 

will  leave  on  the  top  of  the  stack  the  address  of  the  eo-2 
activation  record. 

Following  the  same  reasoning  we  can  see  that  if  eo=3  then 
the  address  of  the  activation  record  is  computed  by: 

P'JSHEP 

VAL 

VAL 

In  general,  the  code  to  access  the  activation  record  at  static 
distance  eo  is  PJJSHEP  followed  by  ep-i  VALs.  We  will  write  this: 


P'JSHEP 

(ep-i )  *  {  VAL 

u,e  have  seen  how  to  use  the  ep  Dart  of  a  variable's  coordinates 
to  qet  to  che  activation  record  in  which  it  resides.  We  will  now 
investigate  the  use  of  the  vd  cart  to  locate  che  variable  within 
that  activation  record.  figure  9  shows  an  activation  record  with 
several  measurements  indicated. 


If  base  is  the  base  address  of  the  activation  record  (i.e.  the 
address  of  its  static  link)  then 

base-2-n-vp 

is  the  address  of  the  vo-th  variable  in  that  activation  record. 
We  can  rewrite  this  as 

base  -  (2+n-vp) 

Motice  that  (2+n-vp)  is  a  constant  that  depends  only  on  the  vp 
coordinate  of  the  variable  and  the  number  of  variables  bound  at 
lexical  level  eD.  We  will  call  this  latter  quantity  neD  and 
define 

6(ep,vp)  =  ?.+neD-vn 

Thus  the  address  of  the  variable  with  coordinates  (ec,vp)  is 

baseeo-6 (ep,vp) 

It  is  very  easy  for  a  compiler  to  compute  the  quantity  6(ep,vp); 
it  need  only  keen  track  of  the  number  of  variables  declared  at 
each  lexical  level. 
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Now  we  are  readv  to  nut  together  the  two  Darts  of  the  vari¬ 
able  accessing  mechanism.  To  get  the  address  of  variable  (eo,vo) 
we  need  baseeD,  the  address  of  the  activation  record  at  static 
distance  ep.  This  is  exactly  what  is  computed  by: 

P'JSHEP 

( eo-I )  *  {  ML 

To  get  the  address  of  the  variable  we  must  subtract  $ (eo ,vp) : 

PUSH  6  (en.vD) 

SUB 

Therefore  the  code  for  accessing  the  variable  with  coordinates 
(eD,vp)  and  leaving  its  value  on  the  stack  is: 

Va r  eo , vp  = 

PUSH5P 

( ep-i )  *  {  'ML 

PUSH  6  ( ep ,  vp) 

SUB 

’ML 

We  have  given  this  sequence  of  instructions  the  "macro"  name  Var 
because  it  occurs  so  frequently.  Macros  like  this  are  sometimes 
called  code  skeletons .  por  example,  it  the  coordinates  for  'x' 
are  (3,?.)  and  03  =  3  then  the  code  for  accessing  'x'  is: 

Afx)  =  var  3,2  = 

PUSHHP 

ML 

ML 

PUSH  3 
SUB 

ml 

since  £(3,2)  =  2+D3-2  =  2+3-2  =  3. 

It  must  be  emphasized  again  that  the  L-Code  shown  here  is 
appropriate  to  the  activation  record  format  we  have  chosen.  If 
the  activation  record  format  were  different.  then  ditferent 
instructions  would  be  required.  The  important  ideas  to  remember 
in  accessing  a  variable  with  coordinates  (eo,vp)  are: 

1)  Bind  the  activation  record  holding  the  variable  by  fol¬ 
lowing  the  static  chain  for  a  static  distance  of  eD. 

2)  Use  the  vd  coordinate  to  access  the  variable  within 
activation  record  found  in  step  (1). 


the 
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We  can  now  state  the  translation  rule  for  a  variable  'v' 
with  coordinates  (eo,vp): 

Atv)  =  Var  en,vD 

3  Applications 

Recall  chat  the  steps  involved  in  evaluating  a  application 

are: 

1)  Evaluate  the  operator. 

2)  Evaluate  the  operands. 

3)  Construct  the  environment  of  evaluation. 

4)  Evaluate  the  body  of  the  function  in  this  environment. 

The  code  that  we  produce  for  a  application  will  have  to  perform 
these  same  steps.  It  is: 

At  f (ex , . . . ,en) ] 

Alt] 

At  ei) 


cl?*1 


n 


The  Call  macro  instruction  will  do  the  work  of  constructing  an 
activation  record  for  the  new  environment  and  executing  the  tunc- 
tion  in  that  environment  (steps  (3)  and  (4)). 


EXAMPLE :  Compile  'mod (7, 2)'.  Assume  the  coordinates  of 
'  mod '  are  (3,1). 


At  mod (7,2)  ]  = 


At  mod) 

At7) 

At  2) 

Call  2  = 

Var  3,1 
P'JSH  7 
PUSH  2 
Call  2 

As  noted  above,  the  Call  macro  instruction  is  responsible  for 
building  the  new  activation  record  and  for  entering  the  Pro¬ 
cedure.  Since  the  parameter  values  are  already  stacked,  only  the 
dynamic  and  static  link  parts  of  the  new  activation  record  remain 


# 


i 


d 
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to  be  constructed.  The  steps  are: 

1)  Construct  dynamic  link. 

2)  Construct  static  link. 

.1)  Install  the  new  current  activation  record. 

4)  Enter  the  function. 

since  the  dynamic  link  must  preserve  the  state  of  the  caller  it 
has  two  parts:  an  eo  to  preserve  the  caller's  environment  and  an 
ip  to  Preserve  the  next  instruction  to  execute.  These  can  be 
saved  by  constructing  a  closure: 

PUSHFP 
PUSH  r 
PAIR 

where  r  is  the  address  of  the  next  instruction  following  Call; 
this  is  where  execution  of  the  caller  will  resume  when  the  called 
procedure  returns.  This  leaves  the  stack  in  the  state: 

1 
2 


n+1 
n+2 

The  static  link  must  point  to  the  environment  of  definition  of 
the  procedure.  As  the  above  diagram  indicates,  the  (n+2)  posi¬ 
tion  from  the  top  of  the  stack  contains  a  closure  for  the  pro¬ 
cedure  to  be  called  (this  resulted  from  evaluating  the  operator 
in  step  (1)).  The  static  link  is  constructed  by  extracting  the 
left  half  (eo)  of  this  closure: 

COPY  n+2 
LEFT 

The  third  step,  installing  the  new  current  activation  record,  is 
accomplished  by  placing  the  address  of  the  new  activation  record 
into  the  FP  register.  Since  the  static  link  is  currently  at  the 
top  of  the  stack,  this  is  accomplished  by: 

MARK 


This  leaves  the  stack  in  the  state: 
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1 

2 

3 


n+2 

n+3 


and  completes  construction  or  the  activation  record. 

The  fourth  step  is  to  enter  the  function.  The  address  of 
the  first  instruction  in  the  function  is  contained  in  the  closure 
at  position  (n+3)  in  the  stack.  Thus  transfer  into  the  function 
is  accomplished  by: 

COPY  3+n 

RIGHT 

GOI 


Putting  together  the  entire  instruction  sequence  for  Call  yields: 


Call  n  = 
PUSHEP 
PUSH  r 
PMR 

COPY  n+2 

LEFT 

""ARK 

COPY  n+3 

RIGHT 

GOI 


I 

}  build  DL 

I 

}  build 
}  SL 

}  install  new  AR 
}  get  entry 
}  point 

\  enter  the  function 
}  the  return  location 


It  is  to  be  emphasized  again  that  the  specific  code  sequence 
shown  above  is  not  so  important  as  the  qeneral  steps  involved  in 
a  call: 


1)  Save  the  state  of  the  call  in  the  dynamic  link. 

2)  *iake  the  static  link  from  the  ep  in  the  closure. 

3)  Enter  the  function  at  the  location  determined  by  the 
ip  of  the  closure. 


EXERCISE :  Oesiqn  the  activation  record  format  for  a  computer  with 
which  you  are  familiar.  Write  the  sequence  of  instructions 
necessary  to  do  a  Call  on  this  machine. 

4  Abstractions 


Recall  that  in  the  Eval  interpreter  the  proper  execution  of 
an  abstraction  was  ensured  by  packaging  it  together  with  its 


environment  into  a  closure .  In  the  compiled  case  the  ep  part  or 
a  closure  is  a  pointer  to  the  activation  record  of  definition  and 
the  ip  oart  is  the  address  of  the  first  instruction  ot  the  code 
for  the  abstraction's  body.  This  is  constructed  by: 

PUSHSP 
PUSH  k 
PAIR 

where  ’k'  is  the  entry  address  of  the  function.  The  body  of  an 
abstraction  ’>V’ • • • vn { E } '  is  translated  to: 

k  : 

Am 

Return  n 

where  Return  is  a  "macro"  instruction  described  below.  Since  we 
do  not  want  the  function  body  to  be  executed  before  it  is  called, 
we  must  jump  over  it.  Therefore,  the  translation  of  an  abstrac¬ 
tion  is: 

At^v^  •  •  •  vn{  E }  ]  = 

PUSHRP  ep  I 

PUSH  k  ip  } 

PAIR  I 

GOTO  s  } 

k:Am 

Return  n 
s : 

The  Return  instruction  must  accomplish  the  following  casks: 

1)  Pass  the  r eturned-value  from  the  callee  to  the  caller. 

2)  Restore  the  state  of  the  caller  from  the  dvnamic  link. 

3)  Delete  the  callee's  activation  record. 


build  closure 
skip  body 


The  state  of  the  stack  before  the  Return  is: 


1 

2 

3 

4 


n+3 

n+4 


The  r eturned-value  ('answer'  in  the  above  diagram)  can  be  placed 
above  the  caller's  temporaries  and  two  words  of  the  activation 
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record  deleted  by: 

SWAP  i , n+4 
POP  2 

The  environment  ot  the  caller  is  restored  by: 

COPY  1 

LEFT 

SETEP 


leaving  the  stack  in  the  form: 


The  address  to  which  to  return  to  the  caller 
the  dynamic  link  and  saved  above  the  answer 


is  extracted 
in  the  stack  by: 


from 


RIGHT 

SWAP  1 , n+1 
POP  n 


The  'POP  n'  instruction  deletes  the  n  parameter  values,  exposing 
the  return-address  for  a  001  back  to  the  caller.  The  resulting 
code  is: 


Return  n  = 
SWAP  1 , n+4 
POP  2 
COPY  1 
LEFT 
SETEP 
RIGHT 

SWAP  1 , n+1 
POP  n 
GOI 


}  save  answer 
}  delete  closure,  SL 
I 

}  restore  EP  from  DL 

I 

}  get  return  address  from  DL 
}  save  return  address 
}  delete  parameters 
}  reenter  caller 


5  Conditionals 


The  compiled  L-Oode  for  handling  conditionals  will  operate 
similarly  to  the  Eval  interpreter.  That  is,  for 

[  B  ->  T  )  F  1 


we  must  first  evaluate  B  and  if  it  is  true  evaluate  T, 


otherwise 
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evaluate  F.  The  translation  to  accomplish  this  is: 

Al  !  8  *>  T  I  F  1  ]  = 

A(81 

IF  t 

AlPJ 

COTO  x 
t:  ACT] 
x: 

E  Blocks 

In  section  1.4.20  we  saw  that  the  etficiency  of  blocks 
(local  declarations)  could  be  improved  by  implementing  them  in 
Eval  directly,  rather  than  as  procedure  invocations.  The  same  is 
true  with  respect  to  the  L-Code  implementation  of  blocks,  since  a 
simpler  activation  record  structure  will  suffice  and  since  it 
will  not  be  necessary  to  construct  or  decompose  closures. 
Indeed,  since  a  block  is  always  invoked  in  its  environment  of 
definition,  its  static  and  dynamic  links  are  always  the  same. 
Further,  since  a  block  is  always  invoked  from  the  same  place,  it 
is  not  necessary  to  save  the  IP  of  the  caller.  Although  this 
means  that  these  items  could  be  omitted  entirely  from  the  activa¬ 
tion  record  for  blocks,  we  will  include  space  for  them  so  that 
the  format  will  aqree  with  that  of  a  procedure's  activation 
record.  This  will  allow  us  to  use  the  translation  of  variables 
already  discussed  regardless  of  whether  the  variable  was  bound  by 
a  procedure  or  a  block.  In  an  actual  compiler  we  miqht  choose  to 
use  two  different  formats  at  the  expense  of  a  more  complicated 
translation  process. 

With  this  explanation  done  we  can  proceed  with  the  transla¬ 
tion  of  blocks.  This  makes  use  of  two  "macro"  instructions  which 
create  and  delete  the  block's  activation  record: 

Atlet  v^=e^  and  •••  and  vn=en  in  B)  = 

ACexl 


Beqm 

AT8) 

End  n 

The  Begin  and  End  instructions  are  simplifications  of  Call  and 
Return : 


v 
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Reqin  = 

PUSHUP  }  eo  }  build  DL 

PUS HP  P  } 

MARK  }  install  new  current  AR 

Pnd  n  = 

SWAP  1,3+n  1  save  answer 
POP  2  ]  delete  first  local  and  SL 

}  restore  EP 
SETPP  !  from  DL 

POP  n-i  }  discard  rest  of  locals 
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